[ros-kernel] Hunting a task

[KJK::Hyperion]

At 15.29 17/10/2003, you wrote:
>I was thinking about improoving CMD as was asking Hyperion(I was thinking 
>to replace all the parsing with he program used by all linux commands)

readline? or lex+yacc? both are bad (or at least not very lungimirant) ideas

Line editing, in Windows, is done automatically on the console side when in 
preprocessed input mode, and I'm happier this way. I don't like the vaguely 
fascist take of GNU on the issue: programs shouldn't link to a (GPLed, 
because it's "special") library *explicitely* to support line editing, 
because what you *really* mean when you ReadFile() a console/read() a 
terminal is line-based input with local editing (no, really, you do. The 
Bourne shell means it. Netcat means it. Your average ANSI C program means 
it. When you press Left Arrow you definitely *don't* want to send an ANSI 
escape). Our CMD does line editing by itself only because our CSRSS 
doesn't: a bug in our CSRSS, being explicitely documented that the Windows 
NT line integrates DOSKEY (a DOS driver that hooked console input to 
provide line editing, with history and macros - pretty cool add-on, back in 
the days) functionality natively

Lex and Yacc? CMD has quite an unorthodox parsing algorithm, that nobody 
seems to have duplicated exactly, so far. Based on my observations, I can 
say it parses lines in multiple passes: first it processes line 
continuation escapes ('^' at the end of the line), then it expands 
environment variables (%VARNAME%), then it actually parses the command 
line, with different semantics for each class of commands. Command lines 
for built-ins, like "cd", "dir", "for" etc. are tokenized differently from 
non-built-ins ("cd.exe" is two tokens, "cd" and ".exe", while "blah.exe" is 
a single token), and some built-ins (like "for", "if" and "(" - yes, I'm 
positive that "(" actually is a command) have their own line-input 
functions to allow writing multi-line command lines with a familiar syntax 
(i.e. without the need for line continuation escapes). This pass tokenizes 
the various command lines and interpretes the command line operators ("<", 
">", "|", "&", "&&", etc.). In this pass the syntax !VARNAME! is 
(optionally, not enabled by default) handled by expanding VARNAME - it's a 
handy way to prevent premature expansion of variables in a "for" command 
line or to pass variables containing command line operators without 
escaping them. Remember: CMD doesn't have operators or statements, "if", 
"goto" and "for" are all commands. When input isn't parsed line-by-line, 
it's just because the command is a built-in with a custom input procedure. 
Now, I may not be the greatest expert of Lex and Yacc in the world, but 
this sounds a bit hard to be factorized into a "tokenization + LALR 
parsing" flow