Hush does not handle "set -o pipefail".

[Rob Landley]

Or any set -o for that matter. But pipefail's one that's really hard to work
around if you haven't got it...

Rob

[Christopher Barry]

I find this a fairly useful method in bash, if not perfect.

function pipe_status()
{
local -a pipestatus=( ${@} )
for ((p=0;p<${#pipestatus[@]};p++))
do
if [[ ${pipestatus[${p}]} -ne 0 ]]
then
echo "failure in pipe index ${p} (${pipestatus[${p}]})" >&2
return ${pipestatus[${p}]}
fi
done
return 0
}
#---------------------------------------------------------------------
do | a | really | long | pipe
pipe_status ${PIPESTATUS[@]} || handle_error ${?}


I don't use hush though, so no idea if this will work in that shell or
not.
-C

Post by Rob Landley
Or any set -o for that matter. But pipefail's one that's really hard to work
around if you haven't got it...
Rob

[Denys Vlasenko]

Post by Rob Landley
Or any set -o for that matter. But pipefail's one that's really hard to work
around if you haven't got it...

But this will increase complexity, would it not?

[Rob Landley]

Post by Denys Vlasenko

Post by Rob Landley
Or any set -o for that matter. But pipefail's one that's really hard to
work around if you haven't got it...

But this will increase complexity, would it not?

Are you being facetious? I can't tell in email.

If you can tell me how to both pipe the output of a command to tee _and_ tell
whether nor not the command exited with a nonzero exit code without it, I'm
all ears. I couldn't figure out how to do so without firing up a subshell and
signaling result state via the filesystem, which means adding a trap handler to
clean up the file if it's interrupted (which still won't handle kill -9) and is
basically "too disgusting for words" compared to pipefail. Heck, the BSD guys
backported pipefail to ksh, it's that useful.

Complexity is a cost, the functionality you get in return needs to be worth
that cost. I'm talking about getting the most functionality for the least
complexity. Sometimes you give up functionality that's too complex to be
worth it, and sometimes you have to abandon a wonderfully simple approach
because it just can't do what you need.

If you want to reduce complexity of the project unconditionally, "rm -rf *" in
the source tree can't be beat. You'll never get simpler than the end result
of that.

Rob

[Denys Vlasenko]

Post by Rob Landley

Post by Denys Vlasenko

Post by Rob Landley
Or any set -o for that matter. But pipefail's one that's really hard to
work around if you haven't got it...

But this will increase complexity, would it not?

Are you being facetious? I can't tell in email.

My mail also contained the patch. ;)

Post by Rob Landley
If you can tell me how to both pipe the output of a command to tee _and_ tell
whether nor not the command exited with a nonzero exit code without it, I'm
all ears. I couldn't figure out how to do so without firing up a subshell and
signaling result state via the filesystem, which means adding a trap handler to
clean up the file if it's interrupted (which still won't handle kill -9) and is
basically "too disgusting for words" compared to pipefail. Heck, the BSD guys
backported pipefail to ksh, it's that useful.
Complexity is a cost, the functionality you get in return needs to be worth
that cost. I'm talking about getting the most functionality for the least
complexity. Sometimes you give up functionality that's too complex to be
worth it, and sometimes you have to abandon a wonderfully simple approach
because it just can't do what you need.

I agree. Therefore I applied the patch to git.

[Rob Landley]

Post by Denys Vlasenko

Post by Rob Landley

Post by Denys Vlasenko

Post by Rob Landley
Or any set -o for that matter. But pipefail's one that's really hard
to work around if you haven't got it...

But this will increase complexity, would it not?

Are you being facetious? I can't tell in email.

My mail also contained the patch. ;)

Thanks. It didn't apply to 1.17.3 so making my script work with it is on my
todo list. (I've got somebody interested in poking at aboriginal on real
sparc hardware so I need to buckle down and fix the dynamic linker, and I'm in
the middle of figuring out why the uClibc prebuilt-locale stuff still wants to
call the "locale -a" command on the host, which isn't _there_ on the gentoo
box running my cron jobs, and if throwing one in the path that just echoes "C"
and "POSIX" will satisfy it.)

Oh, by the way, if you point #!/bin/sh to hush and then run the zlib
./configure stage it dies kind of impressively. (The others probably do too,
zlib is just the first package my LFS bootstrap tries to build. Then again the
perl ./configure stage segfaulted repeatedly with #!/bin/sh=ash, so what I
really need to do is finish the lfs-bootstrap script with sh=bash and _then_
see what hush breaks. Right now I'm just trying to get the lfs-bootstrap
scripts _themselves_ to work with hush...)

"So much time, so little to do! ...Strike that. Reverse it." - Willy Wonka

Rob

[Denys Vlasenko]

Post by Rob Landley

Post by Denys Vlasenko

Post by Rob Landley

Post by Denys Vlasenko

Post by Rob Landley
Or any set -o for that matter. But pipefail's one that's really hard
to work around if you haven't got it...

But this will increase complexity, would it not?

Are you being facetious? I can't tell in email.

My mail also contained the patch. ;)

Thanks. It didn't apply to 1.17.3 so making my script work with it is on my
todo list.

I propose that I just release 1.18.0 instead. There are more fixes
in hush which you probably will benefit from.

Post by Rob Landley
(I've got somebody interested in poking at aboriginal on real
sparc hardware so I need to buckle down and fix the dynamic linker, and I'm in
the middle of figuring out why the uClibc prebuilt-locale stuff still wants to
call the "locale -a" command on the host, which isn't _there_ on the gentoo
box running my cron jobs, and if throwing one in the path that just echoes "C"
and "POSIX" will satisfy it.)
Oh, by the way, if you point #!/bin/sh to hush and then run the zlib
./configure stage it dies kind of impressively.

What is the bug or missing feature it stumbled over?

Post by Rob Landley
(The others probably do too,
zlib is just the first package my LFS bootstrap tries to build. Then again the
perl ./configure stage segfaulted repeatedly with #!/bin/sh=ash, so what I
really need to do is finish the lfs-bootstrap script with sh=bash and _then_
see what hush breaks. Right now I'm just trying to get the lfs-bootstrap
scripts _themselves_ to work with hush...)

Please provide me with the precise information what needs to be fixed/implemented,
and I will code it up.

[Rob Landley]

Post by Denys Vlasenko

Post by Rob Landley

Post by Denys Vlasenko

Post by Rob Landley

Post by Denys Vlasenko

Post by Rob Landley
Or any set -o for that matter. But pipefail's one that's really
hard to work around if you haven't got it...

But this will increase complexity, would it not?

Are you being facetious? I can't tell in email.

My mail also contained the patch. ;)

Thanks. It didn't apply to 1.17.3 so making my script work with it is on
my todo list.

I propose that I just release 1.18.0 instead. There are more fixes
in hush which you probably will benefit from.

No objection. Always happy to try new releases...

Post by Denys Vlasenko

Post by Rob Landley
(I've got somebody interested in poking at aboriginal on real
sparc hardware so I need to buckle down and fix the dynamic linker, and
I'm in the middle of figuring out why the uClibc prebuilt-locale stuff
still wants to call the "locale -a" command on the host, which isn't
_there_ on the gentoo box running my cron jobs, and if throwing one in
the path that just echoes "C" and "POSIX" will satisfy it.)
Oh, by the way, if you point #!/bin/sh to hush and then run the zlib
./configure stage it dies kind of impressively.

What is the bug or missing feature it stumbled over?

It's not one thing.

For example, running the ./configure stage of dropbear hangs. It never
produces any output, even if you let it sit there for half an hour. I have no
idea where it's hanging because it doesn't support "set -x". I tried sticking
"echo" lilnes in there but it's autoconf crap doing this horrible stuff with
nested parentheses spanning hundreds of lines (within which there are function
definitions using parentheses of their own) and figuring out the flow control is
non-obvious...

I eventually tracked it down to this blob:

# Name of the executable.
as_me=`$as_basename -- "$0" ||
$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
X"$0" : 'X\(//\)$' \| \
X"$0" : 'X\(/\)' \| . 2>/dev/null ||
echo X/"$0" |
sed '/^.*\/\([^/][^/]*\)\/*$/{
s//\1/
q
}
/^X\/\(\/\/\)$/{
s//\1/
q
}
/^X\/\(\/\).*/{
s//\1/
q
}
s/.*/./; q'`

$as_basename=false $as_expr=expr and $0=./configure

That hangs with hush, but not with ash or bash. No idea why.

Post by Denys Vlasenko

Post by Rob Landley
(The others probably do too,
zlib is just the first package my LFS bootstrap tries to build. Then
again the perl ./configure stage segfaulted repeatedly with
#!/bin/sh=ash, so what I really need to do is finish the lfs-bootstrap
script with sh=bash and _then_ see what hush breaks. Right now I'm just
trying to get the lfs-bootstrap scripts _themselves_ to work with
hush...)

Please provide me with the precise information what needs to be
fixed/implemented, and I will code it up.

If I can find it, I will, but these are large complicated scripts that require
fairly extensive debugging just to figure out what they're _trying_ to do.

Rob

[Denys Vlasenko]

Post by Rob Landley

Post by Denys Vlasenko

Post by Rob Landley
Oh, by the way, if you point #!/bin/sh to hush and then run the zlib
./configure stage it dies kind of impressively.

What is the bug or missing feature it stumbled over?

It's not one thing.

Sure.
I do not expect you to give me the full list of things
which do not work. Just the first one.

Post by Rob Landley
For example, running the ./configure stage of dropbear hangs. ?It never
produces any output, even if you let it sit there for half an hour. ?I have no
idea where it's hanging because it doesn't support "set -x". ?I tried sticking
"echo" lilnes in there but it's autoconf crap doing this horrible stuff with
nested parentheses spanning hundreds of lines (within which there are function
definitions using parentheses of their own) and figuring out the flow control is
non-obvious...
# Name of the executable.
as_me=`$as_basename -- "$0" ||
$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
? ? ? ? X"$0" : 'X\(//\)$' \| \
? ? ? ? X"$0" : 'X\(/\)' \| . 2>/dev/null ||
echo X/"$0" |
? ?sed '/^.*\/\([^/][^/]*\)\/*$/{
? ? ? ? ? ?s//\1/
? ? ? ? ? ?q
? ? ? ? ?}
? ? ? ? ?/^X\/\(\/\/\)$/{
? ? ? ? ? ?s//\1/
? ? ? ? ? ?q
? ? ? ? ?}
? ? ? ? ?/^X\/\(\/\).*/{
? ? ? ? ? ?s//\1/
? ? ? ? ? ?q
? ? ? ? ?}
? ? ? ? ?s/.*/./; q'`
$as_basename=false $as_expr=expr and $0=./configure
That hangs with hush, but not with ash or bash. ?No idea why.

Bug in hush. It usually treats <newline> as ';', and on this line:

echo X/"$0" |

it's a wrong thing to do.
The bug caused next sed to run with fd 0 opened to stdin...

I fixed this in git (along with two other bugs which I noticed
by looking at nearby code: echo ""#foo was treating #foo as comment
and a\<newline>=1 was not treated as assignment).
Added tests to testsuite for each of them.

Post by Rob Landley

Post by Denys Vlasenko
Please provide me with the precise information what needs to be
fixed/implemented, and I will code it up.

If I can find it, I will, but these are large complicated scripts that require
fairly extensive debugging just to figure out what they're _trying_ to do.

Thanks, the report in your mail was exactly what I needed.
No need to dig deeper than that.

I will release 1.18.0 soon.

[Rob Landley]

Post by Denys Vlasenko

Post by Rob Landley
If I can find it, I will, but these are large complicated scripts that
require fairly extensive debugging just to figure out what they're
_trying_ to do.

Thanks, the report in your mail was exactly what I needed.
No need to dig deeper than that.
I will release 1.18.0 soon.

I'll test hush again then, but I note that uClibc is finally making release
noises:

http://lists.uclibc.org/pipermail/uclibc/2010-November/044430.html

Meaning I have to go test that soonish, and I expect that to be a massive
time-sink.

Rob

[Denys Vlasenko]

Post by Rob Landley

Post by Denys Vlasenko

Post by Rob Landley
If I can find it, I will, but these are large complicated scripts that
require fairly extensive debugging just to figure out what they're
_trying_ to do.

Thanks, the report in your mail was exactly what I needed.
No need to dig deeper than that.
I will release 1.18.0 soon.

I'll test hush again then

Great. 1.18.0 is released today.