On 14/06/2022, Nick Bowler <nbowler@xxxxxxxxxx> wrote:
> On 2022-06-14, Michael Orlitzky <michael@xxxxxxxxxxxx> wrote:
>> On Mon, 2022-06-13 at 15:39 -0700, Paul Eggert wrote:
>>>
>>> I've wanted something like this for *years* (I assigned a simpler
>>> version to my undergraduates but of course it was too much to expect
>>> them to implement it) and I hope some sort of parallelization like this
>>> can get into production with Bash at some point (or some other shell if
>>> Bash can't use this idea).
>>>
>>
>> It looks like PaSh itself was designed and built well. The authors use
>> multiple test suites and PaSh is comparable to other shells in
>> correctness. Ultimately you wouldn't want a runtime dependency on
>> python in your /bin/sh, but as a first step... can PaSh run ./configure
>> already?
>
> The answer seems to be no. For fun, I just tried pash-0.8 on a configure
> script and the shell itself crashes immediately.
>
> It was very difficult to install so I might not be smart enough to use it
> and botched the installation. But pash appears to not understand shell
> variables in redirections:
>
> % sh -c 'fd=1; echo hello >&$fd'
> hello
> % pa.sh -c 'fd=1; echo hello >&$fd'
> [multiple pages of python line noise]
> AttributeError: 'LP_union_node' object has no attribute 'narg'
I worked around this problem by changing the command to use eval instead.
Next, it chokes syntax like this:
% sh -c 'case `(echo hello) 2>/dev/null` in *) echo yay ;; esac'
yay
% pa.sh -c 'case `(echo hello) 2>/dev/null` in *) echo yay ;; esac'
/tmp/pash_5xGNxHR/tmpwgw5hrrs: line 1: echo hello 2>/dev/null :
syntax error in expression (error token is "hello 2>/dev/null ")
I changed the configure script to work around this problem.
It also seems to have some bizarre quoting bugs:
% cat >test.sh <<'EOF'
if :; then var='"("'; fi
echo "$var"
EOF
% sh test.sh
"("
% pa.sh test.sh
/tmp/pash_sEonmPK/tmpcmsn6hyd: line 6: syntax error near unexpected token `('
/tmp/pash_sEonmPK/tmpcmsn6hyd: line 6: ` { ( exit
"${pash_runtime_final_status}" ) ; } ; } ; } ; } ; }; then var=""("";
fi'
I worked around this problem in the configure script too.
At this point configure will start to run, but:
configure runs some commands like this:
$SHELL script arguments
This fails when SHELL is pa.sh because an explicit "--" argument is
needed to disable pa.sh's option processing. I worked around this
with the use of a wrapper script to invoke pa.sh.
configure runs config.guess with $CONFIG_SHELL, but this produces
garbage output (multiple lines of C code get printed to standard output)
when run under pa.sh, which ultimately fails when that garbage gets
passed to config.sub. I worked around this problem by replacing
config.guess with a simple one liner.
Now configure runs to completion but the generated config.status script
crashes with more shell syntax problems. I worked around this by
manually running config.status with a different shell.
The resulting config.h is correct but pa.sh took almost 1 minute to run
the configure script, about ten times longer than dash takes to run the
same script. More than half of that time appears to be spent just
loading the program into pa.sh, before a single shell command is
actually executed.
Cheers,
Nick
