Syntactic issues suggestions, some based on rc

[johnwcowan]

In no particular order:

1. The ability to redirect file descriptors other than 0, 1, 2 is not often used but is important to have when constructing graphs (as opposed to pipelines) of commands. I think the rc syntax <[3]foo.bar is better than the Posix syntax 3<foo.bar.

2. You need to say what characters are allowed in a variable name without braces. Also, it seems like variable references are only allowed inside double quotes, which strikes me as an unnecessary restriction. I see no problem with allowing echo $foo as well as echo "$foo".

3. Your quote system is too messy and Posixy. I suggest adopting the rc system, which is this: single-quoted text can run over lines and has only one escape, namely doubled single-quote for a single-quote. Double quotes aren't used. That turns your example echo "xx**\"**xx" into echo 'xx**''**xx. In combination with bare variable interpolation, you can then say 'Hello, '$username', welcome to the system.', which passes just one argument to echo.

4. I like >! better than>! since ! is well understood as "do something destructive". If you want a filename beginning with !, insert a space.

5. Your remark "This avoids inadvertent matching of the names . and .. which mean the current directory and the parent directory, respectively." does not seem to be true of the pattern .*. I always end up writing .[a-zA-Z] instead. It might be good if globs never match . or ...

6. Brace expansion is very handy, and you can distinguish it from C-type braces by requiring the latter to be surrounded by whitespace, as they usually are. So echo {a,b}{c,d} outputs ac ad bc bd. This is not a must.

7. Your syntax command provides unhygienic macros, which will bite users in the butt eventually. The hard part is making sure that names get the bindings in the macro body that are those available where the macro was defined, not where it was called.

[michaelmacinnis]

Thanks for the feedback.

1. Oh specifically avoids numbered file descriptors and the associated syntax. The pipe and chan commands can be (and are) used to construct graphs. This is how process substitution is implemented in oh.

2. The README is fairly explicit about the characters that are allowed in a variable name without braces. I'll see if there is a way to reword or add to that to make it clearer. That section in the README hasn't made it to the manual yet which is being rewritten. Variable references are allowed outside of double quotes: echo $foo works just as well as echo "$foo".

3. It's unlikely that oh will drop double quotes or string interpolation. Those are features people have come to expect in a Unix shell. Also, what you suggest currently works in oh:

define username "John"
echo 'Hello, '$username', welcome to the system.'

4. I like the syntax >! too but >| is unambiguous. Where possible, I try to avoid cases where inserting or removing a space changes the behavior of a command.

5. I agree. That sentence is misleading. I don't believe globs can currently be used to match . or ... At least in the patterns I've tried. If there is a pattern that matches . or .. it is most likely a bug.

6. An early version of oh did support brace expansion but I removed it. I don't like how it interacts with the rest of the language and am looking for an alternative approach.

7. Oh's syntax command is based on Kernel's fexprs. You can read more about them here: https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf I'm quite happy with how fexprs fit and currently have no plans to change how syntax is implemented.

[johnwcowan]

Thanks for the response.

2: I didn't check for features mentioned in the README that aren't in the manual: my bad.

3: People expect command substitution in double quotes too.

7: I do know about Kernel $vau.

[michaelmacinnis]

2: I didn't check for features mentioned in the README that aren't in the manual: my bad.

No way for you to know. My intent was to point you to a spot that might help answer your question. The manual is next on my list of things to improve. Life and work, unfortunately, have a way of intruding.

3: People expect command substitution in double quotes too.

True. These days I would say most people expect bash which oh isn't. The hard part is figuring out where to draw the line.

7: I do know about Kernel $vau.

Excellent.