>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
Received on Mon Apr 02 2018 - 18:11:09 UTC