My reaction:
:) :)
* "Wait, did he rename the C source files too? Like src/execline/=.c, src/execline/;.c, etc.?"
I tried. Really, I tried. The filesystem didn't have any problem with that, nor did shell scripts, provided the appropriate amount of quoting was given; but *make* choked. Seriously. Try to explain to make that you have a target named ";" and that the rule involves a file named ";.o". It might be possible, but even after carefully reading the GNU make manual again, I couldn't get it to work. Don't forget make-3.81 needs to be supported too. So, eventually I settled for a hack. It's not like this branch is going to be heavily maintained anyway.
* "Wait, execline commands exist as executable files in the filesystem, are the files going to actually have those names? Like 'test' and '['? That new makefile is going to be quite interesting..."
Yes, the Makefile was just impossible to craft. But the command names work, flawlessly. Try it: ";" and "&" are perfectly valid names for executables, and they're not special characters for execlineb, so there's no problem. You can even run them from a shell if you don't mind quoting nightmares.
* "Wait, are programs still going to be callable by their old names?" - "How? Compatilibity symlinks? Didn't he dislike multiple personality binaries?
Compatibility hard links, in this case, but symlinks would work too. Yes, I dislike multiple personality binaries, but this is not what's happening here: "background" and "&" have the same personality, they do the exact same thing, they're just present under two different names. There's no switching on argv[0]. Of course, it means that stderr messages will print "&" as program name even if you call it as "background". I figured it wasn't worth spending more time on this. :P
Is execlineb going to implement the conversion as part of its parsing?" (the latter could actually work?)
That would be extremely difficult, because there's no way for execlineb to know if a "background" string in the argv it's building will be invoked as an executable down the road, or given as an argument to another program. It doesn't know how the command chain is broken down ahead of executing it. Only executables themselves know how many arguments they eat and what they chain-load into.
- "Does every execline script need to be rewritten now? How many of those are out there already?"
That was pretty much the pang of fear I hoped to create, right next to its "how nightmarishly unreadable is that thing becoming?" sibling.
* "Hmmm, using execline commands from a shell is going to be hell now with all that character escaping."
That's entirely part of the fun!
4) "I definitely have to take a closer look now." 5) "Oh."
The secret is revealed in the very commit leading to the v2.4.0.0 tag. It doesn't take a very deep investigation to find out. :) Still, you may or may not be surprised to learn that someone actually sent a PR to a distribution to update the execline package to 2.4.0.0, without taking a look at what was inside. As flattered as I am for the vote of confidence, I shredded the guy for his lousy integration practice. And this is why 2.5.0.0 came out so fast: I don't want people who auto-update to the latest version to have unpleasant surprises and then blame it on me. -- Laurent
