[ros-kernel] Hunting a task

[Waldo Alvarez Cañizares - another buried alive]

Hi KJK::Hyperion:

I think you interpreted thigns in another way. Excuseme for not being more 
specific. I was not thinking about 
lex+yacc. It is too much complex. Neither line editing in CMD. I was 
thinking about this command line 
parser generator genparse-0.5.2.tar.gz stored in sourceforge.net . It is 
simple and I think that I can modify it or ask support for windows to use 
it in command line arguments parsing. Specially in CMD as it has a lot of 
internal commands. In that way if I want to fix some bug in the parsing 
process or speed it up I will only need to change the little text it uses 
or one of the sources it contains. This will also help reduce size of 
source code in CMD and any other application in ROS  for example in 
ROSAPPS. Also implementing more commands would be easier i think. Programs 
in Linux does it that way as says in it's README file. I 
thik is a good Idea to do the same too.

Best regards
Waldo

On Sun, 19 Oct 2003, KJK::Hyperion wrote:

> 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 
> 
> _______________________________________________
> Ros-kernel mailing list
> Ros-kernel at reactos.com
> http://reactos.geldorp.nl:8080/mailman/listinfo/ros-kernel
>