fish-users — General discussion list for fish users

Re: [Fish-users] Bug: login shell with error

[Axel L. <f9...@na...>]

On Mon, 24 Oct 2005, Wolfgang Lauterbach wrote:

> Hi,
>
> my system is  Debian Sarge, updated to testing/unstable. Fish is installed
> with prefix=/usr. When I try to use fish (1.16.0 and below) as a login shell
> for a user, it doesn't work without changes.
>
> from env.c line 45:
> /**
>    Command used to start fishd
> #define FISHD_CMD L"if which fishd >/dev/null; fishd ^/tmp/fish.%s.log; end"
> */
> ==> error: can't find which
>
> changed to:
> #define FISHD_CMD L"/usr/bin/fishd ^/tmp/fish.%s.log"
> 				      ========
> ==> absolute path works for me,
>
> as well as in /etc/fish lines 19 - 26 setting the PATH variable only works
> with absolute path for the test, echo and grep command. After the PATH
> variable is set, everything works fine.
> But it should not be a final solution to set absolute path, should it?

Hmm, I see. These problems are all obviously caused by depending on a
nice, long PATH variable before one can be sure that it really is
defined.

One can solve this either by manually making sure all the common
directories are included before initializing fish, or by beeing very,
very careful during setup to make sure things happen in the proper
order. I'm thinking that the first approach is better, because the
second seems inherently fragile, it would probably end up breaking
again in the future.

Either way, this should be fixed before the next fish release.

Thanks for the bug report!

>
> Have a nice day
>
> Wolfgang
>
> --
> This is Linux country. If you listen carefully, you can hear Windows reboot...

-- 
Axel

[Fish-users] Bug: login shell with error

[Wolfgang L. <lau...@ne...>]

Hi,

my system is  Debian Sarge, updated to testing/unstable. Fish is installed=
=20
with prefix=3D/usr. When I try to use fish (1.16.0 and below) as a login sh=
ell=20
for a user, it doesn't work without changes.=20

from env.c line 45:
/**
   Command used to start fishd
#define FISHD_CMD L"if which fishd >/dev/null; fishd ^/tmp/fish.%s.log; end"
*/=20
=3D=3D> error: can't find which

changed to:
#define FISHD_CMD L"/usr/bin/fishd ^/tmp/fish.%s.log"
				      =3D=3D=3D=3D=3D=3D=3D=3D	=09
=3D=3D> absolute path works for me,

as well as in /etc/fish lines 19 - 26 setting the PATH variable only works=
=20
with absolute path for the test, echo and grep command. After the PATH=20
variable is set, everything works fine.
But it should not be a final solution to set absolute path, should it?

Have a nice day

Wolfgang

=2D-=20
This is Linux country. If you listen carefully, you can hear Windows reboot=
=2E..

[Fish-users] New fish version, 1.16.0

[Axel L. <f9...@na...>]

I've released fish 1.16.0. The major new features are the new event
trigger code, umask and ulimit implementations and the psub function.


-- 
Axel

Re: Resend: Re: [Fish-users] Process substitution workalike now implemented

[Axel L. <f9...@na...>]

On Sat, 22 Oct 2005, Netocrat wrote:

> Axel Liljencrantz wrote:
> > On Fri, 21 Oct 2005, Netocrat wrote:
> >>Axel Liljencrantz wrote:
> [...]
> >>>I just wish someone would write a sane shell without all
> >>>this Posix braindamage...
> >>
> >>Maybe you should ask around and see if anyone's willing?
> >
> > Maybe you'd like to get involved in a project like that? :-D
>
> Wouldn't be seen near it.
>
> >>[unmatching wildcards becoming empty strings]
> [...]
> >>Are you proposing that even if *.c matches, the command does not run and
> >>an error message like:
> >>fish: *.h did not match anything
> >>is displayed?
> >
> > Hadn't thought about that. But I agree with your wildcard expantion
> > merging idea. Only when _all_ wildcards produce no matches will it
> > result in an error and no execution. Just checked, and that is indeed
> > exactly what tcsh does.
>
> On the other hand zsh (at least with the default settings - it seems to
> have the opposite philosophy to fish re configurability) prints an error
> message and stops if only one wildcard does not match.

While both zsh and fish strive to be powerful and featureful,
they are very much each others opposite in some ways. I'm sure zsh
can be made to do anything, if you just find the right combination of
switches. But I think the tcsh way is the right one here.

>
> > There are so many things that tcsh gets right.
>
> That's one of them...
>
> > And so many more that it gets completely wrong.
>
> ...and then typing in foreach(*.h *.c) at the console, one is forced to
> retype the loop body each time at a "foreach?" prompt even though
> there's a command history that recalls the foreach statement.

The list goes ever on and on...

>
> [separate call for developer-focussed debug messages]
> > I'm not sure there really is such a strong distinction between
> > developer messages and user messages. All unimportant messages are
> > meaningless chatter about opening file descriptors, running
> > initializers and other things no sane person wants to know about. In
> > the end, all user oriented messages are developer messages of high
> > priority, at least that is my experience. Can you give me an example
> > of the opposite?
>
> Really this suggestion boils down to a quality-assurance mechanism.
> Most if not all of my temporary ad-hoc debug messages are commented out
> or removed when they've served their purpose.  But it would be useful to
> know that if there happen to be any floating around at release-build
> time, they can be avoided by defining NDEBUG.
>
> Examples of the types of messages I'm talking about are those that are
> unclearly worded (one's mind is on other things than clear wording when
> debugging) and highly specific: printing out temporary or intermediate
> variable contents, etc - the sort of debugging that one might do using
> gdb but that I prefer to do through generous use of very ad-hoc debug
> messages.
>
> An alternative to compiling them out of production releases is to leave
> them in but to precede each with a tagline as well as source code
> filename and line number; and have it configurable whether to display
> such messages (along with debug level as you suggest).

You know how much I _love_ configuration options! ;-)

>
> A second dimension can also be a good idea.  Define a group of debug
> category macros, each being an integer constant with a single unique bit
> set.  Then call debug() with a particular set of these macros bitwise
> or'd; within the debug macro/function test if the current debug category
> mask (potentially settable at runtime) matches any of the categories in
> the mask passed in before printing it.
>
> That makes it easy to get very specific messages without overwhelming
> the console with a lot of unrelated messages, which is what currently
> happens when fish's debug level is set high.

The argument comes down to wanting to make a distinction
between between user friendly messages and user hostile messages,
with the goal of making sure that all messages shown to the user are
user friendly. Thing is, if the debug messages aren't printed on the
users machine, he will get _no_ error reporting when something
potentially bad happens, which is often even worse than a cryptic
message.

>
> --
> http://members.dodo.com.au/~netocrat
>

-- 
Axel

Re: Resend: Re: [Fish-users] Process substitution workalike now implemented

[Netocrat <net...@do...>]

Axel Liljencrantz wrote:
> On Fri, 21 Oct 2005, Netocrat wrote:
>>Axel Liljencrantz wrote:
[...]
>>>I just wish someone would write a sane shell without all
>>>this Posix braindamage...
>>
>>Maybe you should ask around and see if anyone's willing?
> 
> Maybe you'd like to get involved in a project like that? :-D

Wouldn't be seen near it.

>>[unmatching wildcards becoming empty strings]
[...]
>>Are you proposing that even if *.c matches, the command does not run and
>>an error message like:
>>fish: *.h did not match anything
>>is displayed?
> 
> Hadn't thought about that. But I agree with your wildcard expantion
> merging idea. Only when _all_ wildcards produce no matches will it
> result in an error and no execution. Just checked, and that is indeed
> exactly what tcsh does. 

On the other hand zsh (at least with the default settings - it seems to 
have the opposite philosophy to fish re configurability) prints an error 
message and stops if only one wildcard does not match.

> There are so many things that tcsh gets right. 

That's one of them...

> And so many more that it gets completely wrong.

...and then typing in foreach(*.h *.c) at the console, one is forced to 
retype the loop body each time at a "foreach?" prompt even though 
there's a command history that recalls the foreach statement.

[separate call for developer-focussed debug messages]
> I'm not sure there really is such a strong distinction between
> developer messages and user messages. All unimportant messages are
> meaningless chatter about opening file descriptors, running
> initializers and other things no sane person wants to know about. In
> the end, all user oriented messages are developer messages of high
> priority, at least that is my experience. Can you give me an example
> of the opposite?

Really this suggestion boils down to a quality-assurance mechanism. 
Most if not all of my temporary ad-hoc debug messages are commented out 
or removed when they've served their purpose.  But it would be useful to 
know that if there happen to be any floating around at release-build 
time, they can be avoided by defining NDEBUG.

Examples of the types of messages I'm talking about are those that are 
unclearly worded (one's mind is on other things than clear wording when 
debugging) and highly specific: printing out temporary or intermediate 
variable contents, etc - the sort of debugging that one might do using 
gdb but that I prefer to do through generous use of very ad-hoc debug 
messages.

An alternative to compiling them out of production releases is to leave 
them in but to precede each with a tagline as well as source code 
filename and line number; and have it configurable whether to display 
such messages (along with debug level as you suggest).

A second dimension can also be a good idea.  Define a group of debug 
category macros, each being an integer constant with a single unique bit 
set.  Then call debug() with a particular set of these macros bitwise 
or'd; within the debug macro/function test if the current debug category 
mask (potentially settable at runtime) matches any of the categories in 
the mask passed in before printing it.

That makes it easy to get very specific messages without overwhelming 
the console with a lot of unrelated messages, which is what currently 
happens when fish's debug level is set high.

-- 
http://members.dodo.com.au/~netocrat

Re: Resend: Re: [Fish-users] Process substitution workalike now implemented

[Axel L. <f9...@na...>]

On Fri, 21 Oct 2005, Netocrat wrote:

> Axel Liljencrantz wrote:
>
> [not quoting variables in bash]
[...]
>
> > I just wish someone would write a sane shell without all
> > this Posix braindamage...
>
> Maybe you should ask around and see if anyone's willing?

Maybe you'd like to get involved in a project like that? :-D

[psub stuff]
>
> [glibc error messages]
> > But the fact remans, I use
> > Valgrind on fish a lot, and I never get any memory allocation errors.
> > This probably means that either you do something in fish that I don't
> > do, or youir system is subtly different from mine. If you could tell
> > me just what you where doing before the error, it would be very
> > helpful.
>
> As far as I recall, the errors all occurred around the use of the tstp
> script - I have fish and bash versions of it and I don't know whether
> the messages occurred more or less with either version.  The error
> message I quoted in the last post occurred when I omitted the |psub from
> the command substitution arguments.

Ok. I'll try to reproduce this. But on my machines, fish is currently
very solid and stable. It is not the ideal debug method, but maybe
the only way to weed this out is to release a new version and see if
you are the only one with this issue.

>
> [unmatching wildcards becoming empty strings]
> >>>Reasonable things that will do the wrong thing:
> >>>
> >>>count *.c
> >>>
> >>>for i in *.c *.h; ...; end
> [...]
> > I was mostly thinking of the case where *.c has matches but *.h does
> > not. I think it is wrong, and it will indeed look silly if the body
> > of the loop is something like:
> >
> > echo File $i is (wc -l $i|cut -d " " -f 1) lines long
> >
> > Resulting in output like:
> >
> > File foo.c is 12 lines long
> > File bar.c is 17 lines long
> > wc: : No such file or directory
> >
> > Which is silly, IMO. It should just print the matces and be done
> > with.
>
> In a situation like this one normally doesn't mind if one of the matches
> fails, as long as at least one succeeds.
>
> So it's preferable for consecutive wildcard expansions to merge, in
> which case there would be no empty string and no error.
>
> Are you proposing that even if *.c matches, the command does not run and
> an error message like:
> fish: *.h did not match anything
> is displayed?

Hadn't thought about that. But I agree with your wildcard expantion
merging idea. Only when _all_ wildcards produce no matches will it
result in an error and no execution. Just checked, and that is indeed
exactly what tcsh does. There are so many things that tcsh gets
right. And so many more that it gets completely wrong.

>
> [...]
> >>You seem to be suggesting that debug messaging should be integrated with
> >>user-oriented messaging, which would need a bit of careful planning to
> >>avoid messages confusing to the average end-user.
> >
> > More or less. The debug function takes a severity parameter. One
> > could use something like the following level meanings for it:
> >
> > 0) Critical fish errors that imply a fish bug, lead to shutdown or
> > has some other serious side-effect.
> > 1) Syntax error, network error or other non-critical but important
> > error
> > 2) Warning, non-common behaviour (non-matching wilcards go here)
> > 3+) Meaningless chatter (Only useful for debuging)
> >
> > I would have lined up such a set of guidelines sooner, but I wanted
> > to try out how many different levels felt meaningful, and if a
> > one-dimensional purpose-encoding is enough. After trying it out in
> > code for I while, I think it feels pretty much right. If you think a
> > two-dimensional description, i.e. separate fields for severity and
> > message type makes sense, or if you wish to have more or fewer
> > levels, etc. you are very much welcome to motivate this. I've come up
> > with the above by messing arouynd with severity for various messages,
> > as well as changing the debug_level, which is the flag deciding what
> > messages should be printed.
>
> Separating developer-focussed messages from user-focussed or general
> messages is a good idea.  Developer-focussed messages are often ad-hoc
> and confusing for the end-user.
>
> Instead of an extra dimension, it's enough to use two macros: debug()
> and message().  They would call the same underlying macro/function, but
> the call to the underlying macro/function from debug() would be wrapped
> in assert() so that it could be totally compiled out by defining NDEBUG.
>
> That way levels 3+ could have more specific meaning and it would not be
> disastrous for the end-user to enable printing at those levels
> (presumably most of the messages at those levels would be called with
> debug() anyway).
>
> Typical development process would be something like:
> * write some new code with by-design message() calls as well as ad-hoc
> debug() calls at varying levels
> * get the code working, reword any of the more useful debug() calls as
> end-user-friendly message() calls at an appropriate level - e.g. to
> provide information for bug reporting but without inundating the user
> with a whole lot of ad-hoc messages.

I'm not sure there really is such a strong distinction between
developer messages and user messages. All unimportant messages are
meaningless chatter about opening file descriptors, running
initializers and other things no sane person wants to know about. In
the end, all user oriented messages are developer messages of high
priority, at least that is my experience. Can you give me an example
of the opposite?

>
> --
> http://members.dodo.com.au/~netocrat
>

-- 
Axel

Re: Resend: Re: [Fish-users] Process substitution workalike now implemented

[Netocrat <net...@do...>]

Axel Liljencrantz wrote:

[not quoting variables in bash]
> Again? I don't know how may times that has bitten me, I swear.

It effects everyone - time-to-lightbulb for each instance seems to be 
random and capricious. :-/

> Scratch that, bash is not to blame, it is Canadas fault. Er, I mean
> Posix. I _really_ don't like automatic wildcard expantion of variable
> content.

POSIX syntax is concise but arcane and full of traps for the unwary the 
experienced alike.  Automatic wildcard expansion is one of the traps but 
fortunately it's simple to avoid - always quote variables unless you 
have a specific reason not to.  This also deals with unset variables.

> I just wish someone would write a sane shell without all
> this Posix braindamage...

Maybe you should ask around and see if anyone's willing?

[...]
> [T]he point is that [reopening a named pipe] often won't
> work, and that this is not the fault of fish but standard behaviour
> for pipes. So it seems to me the psub function is up and working.

Agreed.

[...]
> Since it is easy to work around, I don't have any major issue with
> this behavious. I do have issues with the fact that it is not very
> clearly documented, though.

Neither the man page nor SUS describe whether the contents of the pipe 
are lost after closing and what happens when multiple readers try to 
connect to and read from a named pipe.  This would be simple to discover 
using some tests, but it is a little sparsely documented.

[glibc error messages]
> But the fact remans, I use
> Valgrind on fish a lot, and I never get any memory allocation errors.
> This probably means that either you do something in fish that I don't
> do, or youir system is subtly different from mine. If you could tell
> me just what you where doing before the error, it would be very
> helpful.

As far as I recall, the errors all occurred around the use of the tstp 
script - I have fish and bash versions of it and I don't know whether 
the messages occurred more or less with either version.  The error 
message I quoted in the last post occurred when I omitted the |psub from 
the command substitution arguments.

[unmatching wildcards becoming empty strings]
>>>Reasonable things that will do the wrong thing:
>>>
>>>count *.c
>>>
>>>for i in *.c *.h; ...; end
[...]
> I was mostly thinking of the case where *.c has matches but *.h does
> not. I think it is wrong, and it will indeed look silly if the body
> of the loop is something like:
> 
> echo File $i is (wc -l $i|cut -d " " -f 1) lines long
> 
> Resulting in output like:
> 
> File foo.c is 12 lines long
> File bar.c is 17 lines long
> wc: : No such file or directory
> 
> Which is silly, IMO. It should just print the matces and be done
> with.

In a situation like this one normally doesn't mind if one of the matches 
fails, as long as at least one succeeds.

So it's preferable for consecutive wildcard expansions to merge, in 
which case there would be no empty string and no error.

Are you proposing that even if *.c matches, the command does not run and 
an error message like:
fish: *.h did not match anything
is displayed?

[...]
>>You seem to be suggesting that debug messaging should be integrated with
>>user-oriented messaging, which would need a bit of careful planning to
>>avoid messages confusing to the average end-user.
> 
> More or less. The debug function takes a severity parameter. One
> could use something like the following level meanings for it:
> 
> 0) Critical fish errors that imply a fish bug, lead to shutdown or
> has some other serious side-effect.
> 1) Syntax error, network error or other non-critical but important
> error
> 2) Warning, non-common behaviour (non-matching wilcards go here)
> 3+) Meaningless chatter (Only useful for debuging)
> 
> I would have lined up such a set of guidelines sooner, but I wanted
> to try out how many different levels felt meaningful, and if a
> one-dimensional purpose-encoding is enough. After trying it out in
> code for I while, I think it feels pretty much right. If you think a
> two-dimensional description, i.e. separate fields for severity and
> message type makes sense, or if you wish to have more or fewer
> levels, etc. you are very much welcome to motivate this. I've come up
> with the above by messing arouynd with severity for various messages,
> as well as changing the debug_level, which is the flag deciding what
> messages should be printed.

Separating developer-focussed messages from user-focussed or general 
messages is a good idea.  Developer-focussed messages are often ad-hoc 
and confusing for the end-user.

Instead of an extra dimension, it's enough to use two macros: debug() 
and message().  They would call the same underlying macro/function, but 
the call to the underlying macro/function from debug() would be wrapped 
in assert() so that it could be totally compiled out by defining NDEBUG.

That way levels 3+ could have more specific meaning and it would not be 
disastrous for the end-user to enable printing at those levels 
(presumably most of the messages at those levels would be called with 
debug() anyway).

Typical development process would be something like:
* write some new code with by-design message() calls as well as ad-hoc 
debug() calls at varying levels
* get the code working, reword any of the more useful debug() calls as 
end-user-friendly message() calls at an appropriate level - e.g. to 
provide information for bug reporting but without inundating the user 
with a whole lot of ad-hoc messages.

-- 
http://members.dodo.com.au/~netocrat

Re: [Fish-users] Process substitution workalike now implemented

[Netocrat <net...@do...>]

Axel Liljencrantz wrote:
> On Tue, 18 Oct 2005, Netocrat wrote:
[...]
> Bash seems to kill background jobs in command substitutions before
> they finish, or something similar, while zsh and fish don't. I'd
> argue that the fish/zsh behaviour has more uses.

Agreed.

[on psub bug when implemented as backgrounded cat to named pipe]
> Intresting. I can reproduce this bug on one machine, but the code
> works perfectly on another. (Both machines use Fedora Core 4, the one
> where this works is much faster and uses nfs)
[...]
> I'm thinking that perhaps the original tstp implementation has
> problems caused by buffering of stdin or something like that.

Buffering by fish, the C runtime library or the OS?

> I am not surprised at finding bugs when doing this, though.
> Background jobs in command substitutions that write to fifos read by
> the calling job is definitely a bit of an edge case.

Agreed - as evidenced by bash and zsh behaving differently.

[glibc malloc error messages in fish]
> Ouch. That is not good at all. I am running fish through Valgrind a
> lot, to find and identify any memory handling errors. But I'm not
> finding anything.

Well my fish build includes my conditional array conversion patches with 
which I resolve merge conflicts as they arise, so there's some chance of 
a bug introduced through the resolution process there.

>>Also I've noticed that filename completion sometimes displays a
>>messed-up list 
[...]
> This is an old bug, at least a month
> old, it's even mentioned in the known bugs section. 

I didn't check but I see now that it's there.

[...]
>>And I have a suggestion for globbing expansion when the list is empty:
>>expand it to an empty string rather than nothing to prevent this situation:
>>
>>fish> ls /usr/nomatch*
>>[listing of current directory ensues]
>>
>>The alternative is what bash does - expand it to the literal wildcard
>>expression - but I seem to recall you being opposed to that which seems
>>reasonable.
> 
> The alternative that I like the most is this one:
> 
> On regular commands, when a wildcard fails to produce matches, the
> command is not run, and if you are in interactive mode, a warning is
> written. Something like:
> 
> fish: The wildcarded string '*.C' did not result in any matches. The
> command 'ls *.C' will not be executed.

I can't see any problems (except see below) with that as long as it 
doesn't cause output redirection for a pipeline to fail to generate an 
(empty) file which may later be required/tested for:
ls *.c | somecommand > a_file_that_is_later_required_to_be_present

This is mostly relevant to scripts.  Also $status should be set to non-zero.

> One can configure at runtime that some commands should allow
> non-matching wildcards, 

By fish principles options should be avoided and it's possible to avoid 
them here:

The behaviour of not running the command will - in every case I can 
think of that matters - be identical to running the command with an 
empty string (i.e. it will immediately exit with error status) except 
that the command will print its own error message.

The warning message that you suggest for interactive use could be 
printed regardless - it would just be modified to remove the wording 
that the command will not be executed.

[...]
> You should obviously rearrange your priorities so that fish is at the
> very top. :-)

A quite unexpected response. ;-)

[..]
-- 
http://members.dodo.com.au/~netocrat

Re: Resend: Re: [Fish-users] Process substitution workalike now implemented

[Axel L. <f9...@na...>]

On Fri, 21 Oct 2005, Netocrat wrote:

> Axel Liljencrantz wrote:
> > On Thu, 20 Oct 2005, Netocrat wrote:
> >>Axel Liljencrantz wrote:
> [...]
> > I tried to implement the entire test in bashscript, but it doesn't
> > seem to work.
> >
> > The commandline part can be reduced to:
> >
> > mkfifo foo1 foo2; cat ... >foo1& cat ... >foo2& ./foo.sh
> >
> > The tricky part is implementing foo.sh as a bash shellscript. Bash
> > does not like input redirection to builtins, so 'read <foo l' does
> > not seem to work.
>
> Works OK for me.  Probably you got unexpected results because you forgot
> the golden rule of POSIX shell scripting - always quote your variables.
>   The first line of your output begins with /* which when not quoted
> expands to the contents of your root directory.

Again? I don't know how may times that has bitten me, I swear.
Scratch that, bash is not to blame, it is Canadas fault. Er, I mean
Posix. I _really_ don't like automatic wildcard expantion of variable
content. I just wish someone would write a sane shell without all
this Posix braindamage...

>
> > I though I could get around this by using
> >
> > exec <foo
> > read l
>
> Works on my system.
>
> > But that does not seem to work either. Perhaps 'read' does not read
> > from stdin in bash?
>
> It does unless you specify an alternate fd with the -u option.
>
> > Anyway, giving up on bash, I wrote a small utility called 'foo' to
> > open argv[1] and print the first line from it, like so:
> [code ommitted]
> > Combined with the following bash script, called foo2.sh:
> >
> > #!/bin/bash
> >
> > echo \$1 is $1 and \$2 is $2
> > echo The first line of $1 is:
> > ./foo $1
> > echo The next line of $1 is:
> > ./foo $1
> > echo The first line of $2 is:
> > ./foo $2
> > echo The next line of $2 is:
> > ./foo $2
> >
> > And the following line of bash code:
> >
> > rm foo1 foo2; mkfifo foo1 foo2; cat builtin.c >foo1 & cat builtin.c >foo2& ./foo2.sh foo1 foo2
> >
> > I was able to determine that this hangs even when every ounce of fish
> > has been removed from the equation.
>
> Likewise on my system, although it hangs on the second line of the first
> pipe.

If you try it out twenty times on different computers, you will
probably get a few different results. Might even work most of the
time on a few platforms.

>
> > Even more interesting, using the following line of bash code:
> >
> > ./foo2.sh <(cat builtin.c) <(builtin.c)
> >
> > produced:
> >
> > $1 is /dev/fd/63 and $2 is /dev/fd/62
> > The first line of /dev/fd/63 is:
> > Input first line was: /** \file builtin.c
> > The next line of /dev/fd/63 is:
> > Input first line was:  required_argument, 0, 'M'
> > The first line of /dev/fd/62 is:
> > Input first line was: /** \file builtin.c
> > The next line of /dev/fd/62 is:
> > Input first line was:  required_argument, 0, 'M'
> >
> > But 'required_argument...' is _NOT_ the second line of builtin.c, I
> > strongly syspect it is 4Kb into builtin.c, or something like that.
>
> On my system I get the correct results for this using bash's
> redirection.  Your utility's results are explained by C runtime
> buffering (you're using fopen and fgets versus open and read) which is
> lost when you exit the utility.

Yup, that is my belief as well. But the point is that it often won't
work, and that this is not the fault of fish but standard behaviour
for pipes. So it seems to me the psub function is up and working.

>
> > So while bash process substitution fails in a different way with your
> > original code, it still fails.
> >
> > It seems it is not reliable under Linux to open a named pipe for
> > reading, close it and then reopen it to read some more. I don't know
> > if this is legal under Posix or if it is a bug, but it is, as far as
> > I can see, not a fish issue.
>
> I can't see anything in the POSIX standard mandating what happens when a
> named pipe is opened, closed and reopened.  The standard seems to
> specify the behaviour of named pipes very minimally.

Which mostly makes sense and keeps with C tradition, i.e. let the
results of doing stupid things be undefined. I don't think regarding
a pipe as something that you only open and close once is
unreasonable.

>
> According to Linux's mkfifo(3) though:
>
>    Once you have created a FIFO special file in this way, any process  can
>    open  it  for  reading or writing, in the same way as an ordinary file.
>    However, it has to be open at both ends simultaneously before  you  can
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    proceed to do any input or output operations on it.  Opening a FIFO for
>    reading normally blocks until some other process opens  the  same  FIFO
>    for  writing,  and vice versa. See fifo(4) for non-blocking handling of
>    FIFO special files.
>
> So probably when the script opens the fifo for reading for the second
> time, the writing process has already exited and the reading process
> must block waiting for another process to start writing even though
> there is still content in the pipe.
>
> If so, it seems like less than useful behaviour, but then again it's
> probably rare that a pipe will be closed before the reader is completely
> done with it.

Since it is easy to work around, I don't have any major issue with
this behavious. I do have issues with the fact that it is not very
clearly documented, though.

>
> >>[glibc malloc error messages in fish]
> >> > Ouch. That is not good at all. I am running fish through Valgrind a
> >> > lot, to find and identify any memory handling errors. But I'm not
> >> > finding anything.
> >>
> >>Well my fish build includes my conditional array conversion patches with
> >>which I resolve merge conflicts as they arise, so there's some chance of
> >>a bug introduced through the resolution process there.
> >
> > Have you considered using Valgrind for locationg these errors?
>
> Not much.  I just got another one with the most recent version of fish
> from darcs (including my patches):
>
> *** glibc detected *** corrupted double-linked list: 0xb7f6fa4c ***
>
> If these messages occur regularly, I'll take out my patches and see if
> that prevents them but I doubt that the small amount of code I've added
> and the conflict resolution is causing the errors.

Agreed, not only is the patch small, I've looked it over and it seems
to be a very reasonable implementation. But the fact remans, I use
Valgrind on fish a lot, and I never get any memory allocation errors.
This probably means that either you do something in fish that I don't
do, or youir system is subtly different from mine. If you could tell
me just what you where doing before the error, it would be very
helpful.

>
> On a vaguely related note, when I omit the |psub, the following errors
> result and it seems to me that fish could do some better input
> validation and/or provide better error messages here:
>
> fish> ./tstp (cat /data/src-and-projects/fish/builtin.c) (cat
> /data/src-and-projects/fish/builtin.c)
> $1 is /** \file builtin.c and $2 is     Functions for executing builtin
> functions.
> The first line of /** \file builtin.c is:
> wopen: Invalid argument
> pwd: ignoring non-option arguments
> read>

True. I missed making the error message for redirected _builtins_
descriptive. I changed it to the same message as for non-builtin io
redirections:

fish: An error occurred while redirecting file 'gsadlfjs'
open: Invalid argument

I'll probably update it furter to mention the number of the file
descriptor that was to be redirected, and possibly also the job in
which the redirection failed.

>
> [...]
> >> > The alternative that I like the most is this one:
> >> >
> >> > On regular commands, when a wildcard fails to produce matches, the
> >> > command is not run, and if you are in interactive mode, a warning is
> >> > written. Something like:
> >> >
> >> > fish: The wildcarded string '*.C' did not result in any matches. The
> >> > command 'ls *.C' will not be executed.
> >>
> >>I can't see any problems (except see below) with that as long as it
> >>doesn't cause output redirection for a pipeline to fail to generate an
> >>(empty) file which may later be required/tested for:
> >>ls *.c | somecommand > a_file_that_is_later_required_to_be_present
> >
> > touch a_file_that_is_later_required_to_be_present
>
> Well that's possible but why not have fish ensure that it's done so the
> user does not have to deal with it?

It is a question of if we really want to gloss over something that is
broken/wrong bad.

I think it at least as common a situation that if something goes
wrong, you want to properly detect this and stop execution. In such
cases, you want to clean up any files and other resources, which is
easier if you know that broken commands do not create new files.

>
> >>This is mostly relevant to scripts.  Also $status should be set to non-zero.
> >>
> >> > One can configure at runtime that some commands should allow
> >> > non-matching wildcards,
> >>
> >>By fish principles options should be avoided and it's possible to avoid
> >>them here:
> >>
> >>The behaviour of not running the command will - in every case I can
> >>think of that matters - be identical to running the command with an
> >>empty string (i.e. it will immediately exit with error status) except
> >>that the command will print its own error message.
> >
> > Reasonable things that will do the wrong thing:
> >
> > count *.c
> >
> > for i in *.c *.h; ...; end
>
> Either fish agglomerates consecutive wildcard expressions so *.c *.h
> becomes "", or they are treated separately and become "" "".  Even in
> the second less preferable case, the for loop will execute twice with $i
> set to an empty string each time, but the effects of that are dependent
> on which commands are part of the loop body.  I don't see it as
> intrinsically wrong.

I was mostly thinking of the case where *.c has matches but *.h does
not. I think it is wrong, and it will indeed look silly if the body
of the loop is something like:

echo File $i is (wc -l $i|cut -d " " -f 1) lines long

Resulting in output like:


File foo.c is 12 lines long
File bar.c is 17 lines long
wc: : No such file or directory

Which is silly, IMO. It should just print the matces and be done
with.

You can't get all cases right, so I think the best idea is to make
the bahaviour consistent, simple and predictable. Expanding
non-matching wildcards to nothing and raising an error are ok in my
book, expanding to the original string or an empty string are not.
To me, it seems arbitrary, inconsistent and unpredictable. Sure it
works out nicely in some cases, but it breaks in other cases.

>
> > Also, the error messages are not very helpful in saying what is
> > wrong with the command:
> >
> > ls: : No such file or directory
>
> They could be preceded by the warning message you proposed - that's what
> I meant by the quote sentence below.
>
> >>The warning message that you suggest for interactive use could be
> >>printed regardless - it would just be modified to remove the wording
> >>that the command will not be executed.
> >
> > I was thinking that it wouldn't be executed - even in non-interactive
> > mode. The reasoning was that this is not really an error, only a
> > warning, and that it might look unprofessional with lots of debug
> > messages in scripts. I think a better idea is to print these warnings
> > at debug level 2, and by default not print level 2 debug messages in
> > non-interactive, but print them in interactive mode. In the distant
> > future, one could concieve of making the debug level *shudder*
> > configurable.
>
> You seem to be suggesting that debug messaging should be integrated with
> user-oriented messaging, which would need a bit of careful planning to
> avoid messages confusing to the average end-user.

More or less. The debug function takes a severity parameter. One
could use something like the following level meanings for it:

0) Critical fish errors that imply a fish bug, lead to shutdown or
has some other serious side-effect.
1) Syntax error, network error or other non-critical but important
error
2) Warning, non-common behaviour (non-matching wilcards go here)
3+) Meaningless chatter (Only useful for debuging)

I would have lined up such a set of guidelines sooner, but I wanted
to try out how many different levels felt meaningful, and if a
one-dimensional purpose-encoding is enough. After trying it out in
code for I while, I think it feels pretty much right. If you think a
two-dimensional description, i.e. separate fields for severity and
message type makes sense, or if you wish to have more or fewer
levels, etc. you are very much welcome to motivate this. I've come up
with the above by messing arouynd with severity for various messages,
as well as changing the debug_level, which is the flag deciding what
messages should be printed.

>
> --
> http://members.dodo.com.au/~netocrat
>

-- 
Axel

Re: Resend: Re: [Fish-users] Process substitution workalike now implemented

[Netocrat <net...@do...>]

Axel Liljencrantz wrote:
> On Thu, 20 Oct 2005, Netocrat wrote:
>>Axel Liljencrantz wrote:
[...]
> I tried to implement the entire test in bashscript, but it doesn't
> seem to work.
> 
> The commandline part can be reduced to:
> 
> mkfifo foo1 foo2; cat ... >foo1& cat ... >foo2& ./foo.sh
> 
> The tricky part is implementing foo.sh as a bash shellscript. Bash
> does not like input redirection to builtins, so 'read <foo l' does
> not seem to work.

Works OK for me.  Probably you got unexpected results because you forgot 
the golden rule of POSIX shell scripting - always quote your variables. 
  The first line of your output begins with /* which when not quoted 
expands to the contents of your root directory.

> I though I could get around this by using
> 
> exec <foo
> read l

Works on my system.

> But that does not seem to work either. Perhaps 'read' does not read
> from stdin in bash?

It does unless you specify an alternate fd with the -u option.

> Anyway, giving up on bash, I wrote a small utility called 'foo' to
> open argv[1] and print the first line from it, like so:
[code ommitted]
> Combined with the following bash script, called foo2.sh:
> 
> #!/bin/bash
> 
> echo \$1 is $1 and \$2 is $2
> echo The first line of $1 is:
> ./foo $1
> echo The next line of $1 is:
> ./foo $1
> echo The first line of $2 is:
> ./foo $2
> echo The next line of $2 is:
> ./foo $2
> 
> And the following line of bash code:
> 
> rm foo1 foo2; mkfifo foo1 foo2; cat builtin.c >foo1 & cat builtin.c >foo2& ./foo2.sh foo1 foo2
> 
> I was able to determine that this hangs even when every ounce of fish
> has been removed from the equation.

Likewise on my system, although it hangs on the second line of the first 
pipe.

> Even more interesting, using the following line of bash code:
> 
> ./foo2.sh <(cat builtin.c) <(builtin.c)
> 
> produced:
> 
> $1 is /dev/fd/63 and $2 is /dev/fd/62
> The first line of /dev/fd/63 is:
> Input first line was: /** \file builtin.c
> The next line of /dev/fd/63 is:
> Input first line was:  required_argument, 0, 'M'
> The first line of /dev/fd/62 is:
> Input first line was: /** \file builtin.c
> The next line of /dev/fd/62 is:
> Input first line was:  required_argument, 0, 'M'
> 
> But 'required_argument...' is _NOT_ the second line of builtin.c, I
> strongly syspect it is 4Kb into builtin.c, or something like that.

On my system I get the correct results for this using bash's 
redirection.  Your utility's results are explained by C runtime 
buffering (you're using fopen and fgets versus open and read) which is 
lost when you exit the utility.

> So while bash process substitution fails in a different way with your
> original code, it still fails.
> 
> It seems it is not reliable under Linux to open a named pipe for
> reading, close it and then reopen it to read some more. I don't know
> if this is legal under Posix or if it is a bug, but it is, as far as
> I can see, not a fish issue.

I can't see anything in the POSIX standard mandating what happens when a 
named pipe is opened, closed and reopened.  The standard seems to 
specify the behaviour of named pipes very minimally.

According to Linux's mkfifo(3) though:

   Once you have created a FIFO special file in this way, any process  can
   open  it  for  reading or writing, in the same way as an ordinary file.
   However, it has to be open at both ends simultaneously before  you  can
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   proceed to do any input or output operations on it.  Opening a FIFO for
   reading normally blocks until some other process opens  the  same  FIFO
   for  writing,  and vice versa. See fifo(4) for non-blocking handling of
   FIFO special files.

So probably when the script opens the fifo for reading for the second 
time, the writing process has already exited and the reading process 
must block waiting for another process to start writing even though 
there is still content in the pipe.

If so, it seems like less than useful behaviour, but then again it's 
probably rare that a pipe will be closed before the reader is completely 
done with it.

>>[glibc malloc error messages in fish]
>> > Ouch. That is not good at all. I am running fish through Valgrind a
>> > lot, to find and identify any memory handling errors. But I'm not
>> > finding anything.
>>
>>Well my fish build includes my conditional array conversion patches with
>>which I resolve merge conflicts as they arise, so there's some chance of
>>a bug introduced through the resolution process there.
> 
> Have you considered using Valgrind for locationg these errors?

Not much.  I just got another one with the most recent version of fish 
from darcs (including my patches):

*** glibc detected *** corrupted double-linked list: 0xb7f6fa4c ***

If these messages occur regularly, I'll take out my patches and see if 
that prevents them but I doubt that the small amount of code I've added 
and the conflict resolution is causing the errors.

On a vaguely related note, when I omit the |psub, the following errors 
result and it seems to me that fish could do some better input 
validation and/or provide better error messages here:

fish> ./tstp (cat /data/src-and-projects/fish/builtin.c) (cat 
/data/src-and-projects/fish/builtin.c)
$1 is /** \file builtin.c and $2 is     Functions for executing builtin 
functions.
The first line of /** \file builtin.c is:
wopen: Invalid argument
pwd: ignoring non-option arguments
read>

[...]
>> > The alternative that I like the most is this one:
>> >
>> > On regular commands, when a wildcard fails to produce matches, the
>> > command is not run, and if you are in interactive mode, a warning is
>> > written. Something like:
>> >
>> > fish: The wildcarded string '*.C' did not result in any matches. The
>> > command 'ls *.C' will not be executed.
>>
>>I can't see any problems (except see below) with that as long as it
>>doesn't cause output redirection for a pipeline to fail to generate an
>>(empty) file which may later be required/tested for:
>>ls *.c | somecommand > a_file_that_is_later_required_to_be_present
> 
> touch a_file_that_is_later_required_to_be_present

Well that's possible but why not have fish ensure that it's done so the 
user does not have to deal with it?

>>This is mostly relevant to scripts.  Also $status should be set to non-zero.
>>
>> > One can configure at runtime that some commands should allow
>> > non-matching wildcards,
>>
>>By fish principles options should be avoided and it's possible to avoid
>>them here:
>>
>>The behaviour of not running the command will - in every case I can
>>think of that matters - be identical to running the command with an
>>empty string (i.e. it will immediately exit with error status) except
>>that the command will print its own error message.
> 
> Reasonable things that will do the wrong thing:
> 
> count *.c
> 
> for i in *.c *.h; ...; end

Either fish agglomerates consecutive wildcard expressions so *.c *.h 
becomes "", or they are treated separately and become "" "".  Even in 
the second less preferable case, the for loop will execute twice with $i 
set to an empty string each time, but the effects of that are dependent 
on which commands are part of the loop body.  I don't see it as 
intrinsically wrong.

> Also, the error messages are not very helpful in saying what is
> wrong with the command:
> 
> ls: : No such file or directory

They could be preceded by the warning message you proposed - that's what 
I meant by the quote sentence below.

>>The warning message that you suggest for interactive use could be
>>printed regardless - it would just be modified to remove the wording
>>that the command will not be executed.
> 
> I was thinking that it wouldn't be executed - even in non-interactive
> mode. The reasoning was that this is not really an error, only a
> warning, and that it might look unprofessional with lots of debug
> messages in scripts. I think a better idea is to print these warnings
> at debug level 2, and by default not print level 2 debug messages in
> non-interactive, but print them in interactive mode. In the distant
> future, one could concieve of making the debug level *shudder*
> configurable.

You seem to be suggesting that debug messaging should be integrated with 
user-oriented messaging, which would need a bit of careful planning to 
avoid messages confusing to the average end-user.

-- 
http://members.dodo.com.au/~netocrat

Re: Resend: Re: [Fish-users] Process substitution workalike now implemented

[Axel L. <f9...@na...>]

On Thu, 20 Oct 2005, Netocrat wrote:

> Axel Liljencrantz wrote:
> [...]
>  > Bash seems to kill background jobs in command substitutions before
>  > they finish, or something similar, while zsh and fish don't. I'd
>  > argue that the fish/zsh behaviour has more uses.
>
> Agreed.
>
> [on psub bug when implemented as backgrounded cat to named pipe]
>  > Intresting. I can reproduce this bug on one machine, but the code
>  > works perfectly on another. (Both machines use Fedora Core 4, the one
>  > where this works is much faster and uses nfs)
>
> [...]
>  > I'm thinking that perhaps the original tstp implementation has
>  > problems caused by buffering of stdin or something like that.
>
> Buffering by fish, the C runtime library or the OS?

Been looking into this, I was thinking about glibc buffering of
streams, but the fish read builtin operates by calling read on file
descriptor 0, so that _should_ not be an issue.

I tried to implement the entire test in bashscript, but it doesn't
seem to work.

The commandline part can be reduced to:

mkfifo foo1 foo2; cat ... >foo1& cat ... >foo2& ./foo.sh

The tricky part is implementing foo.sh as a bash shellscript. Bash
does not like input redirection to builtins, so 'read <foo l' does
not seem to work. I though I could get around this by using

exec <foo
read l

But that does not seem to work either. Perhaps 'read' does not read
from stdin in bash?

Anyway, giving up on bash, I wrote a small utility called 'foo' to
open argv[1] and print the first line from it, like so:

#include <stdlib.h>
#include <stdio.h>

int main( int argc, char **argv )
{
    FILE *f = fopen( argv[1], "r" );
    char l[1024];

    if( !f )
    {
        perror( "fopen" );
        return 1;
    }

    if( !fgets( l, 1024, f ) )
    {
        perror( "fgets" );
        return 1;
    }

    if( fclose( f ) )
    {
	perror( "fclose" );
        return 1;
    }

    printf( "Input first line was: %s", l );
    return 0;
}

Combined with the following bash script, called foo2.sh:

#!/bin/bash

echo \$1 is $1 and \$2 is $2
echo The first line of $1 is:
./foo $1
echo The next line of $1 is:
./foo $1
echo The first line of $2 is:
./foo $2
echo The next line of $2 is:
./foo $2

And the following line of bash code:

rm foo1 foo2; mkfifo foo1 foo2; cat builtin.c >foo1 & cat builtin.c >foo2& ./foo2.sh foo1 foo2

I was able to determine that this hangs even when every ounce of fish
has been removed from the equation.

Even more interesting, using the following line of bash code:

./foo2.sh <(cat builtin.c) <(builtin.c)

produced:

$1 is /dev/fd/63 and $2 is /dev/fd/62
The first line of /dev/fd/63 is:
Input first line was: /** \file builtin.c
The next line of /dev/fd/63 is:
Input first line was:  required_argument, 0, 'M'
The first line of /dev/fd/62 is:
Input first line was: /** \file builtin.c
The next line of /dev/fd/62 is:
Input first line was:  required_argument, 0, 'M'

But 'required_argument...' is _NOT_ the second line of builtin.c, I
strongly syspect it is 4Kb into builtin.c, or something like that.
So while bash process substitution fails in a different way with your
original code, it still fails.

It seems it is not reliable under Linux to open a named pipe for
reading, close it and then reopen it to read some more. I don't know
if this is legal under Posix or if it is a bug, but it is, as far as
I can see, not a fish issue.

>
>  > I am not surprised at finding bugs when doing this, though.
>  > Background jobs in command substitutions that write to fifos read by
>  > the calling job is definitely a bit of an edge case.
>
> Agreed - as evidenced by bash and zsh behaving differently.

Yup. Fish seems to work pretty well for common use cases, so such
unorthodox useage is probably the best way to weed out more fish
bugs.

>
> [glibc malloc error messages in fish]
>  > Ouch. That is not good at all. I am running fish through Valgrind a
>  > lot, to find and identify any memory handling errors. But I'm not
>  > finding anything.
>
> Well my fish build includes my conditional array conversion patches with
> which I resolve merge conflicts as they arise, so there's some chance of
> a bug introduced through the resolution process there.

Have you considered using Valgrind for locationg these errors?

>
>  > On Tue, 18 Oct 2005, Netocrat wrote:
>  >> Also I've noticed that filename completion sometimes displays a
>  >> messed-up list
> [...]
>  > This is an old bug, at least a month
>  > old, it's even mentioned in the known bugs section.
>
> I didn't check but I see now that it's there.

Partially my fault, since the list is not visible enough and also not
always up-to-date. The whole documentation system should ideally be
redesigned, but the current system, while lacking, is good enough to
get by on, and there are so many things to do.

>
> [...]
>
> >> And I have a suggestion for globbing expansion when the list is empty:
> >> expand it to an empty string rather than nothing to prevent this situation:
>  >>
>  >> fish> ls /usr/nomatch*
>  >> [listing of current directory ensues]
>  >>
>  >> The alternative is what bash does - expand it to the literal wildcard
> >> expression - but I seem to recall you being opposed to that which seems
>  >> reasonable.
>  >
>  > The alternative that I like the most is this one:
>  >
>  > On regular commands, when a wildcard fails to produce matches, the
>  > command is not run, and if you are in interactive mode, a warning is
>  > written. Something like:
>  >
>  > fish: The wildcarded string '*.C' did not result in any matches. The
>  > command 'ls *.C' will not be executed.
>
> I can't see any problems (except see below) with that as long as it
> doesn't cause output redirection for a pipeline to fail to generate an
> (empty) file which may later be required/tested for:
> ls *.c | somecommand > a_file_that_is_later_required_to_be_present

touch a_file_that_is_later_required_to_be_present

>
> This is mostly relevant to scripts.  Also $status should be set to non-zero.
>
>  > One can configure at runtime that some commands should allow
>  > non-matching wildcards,
>
> By fish principles options should be avoided and it's possible to avoid
> them here:
>
> The behaviour of not running the command will - in every case I can
> think of that matters - be identical to running the command with an
> empty string (i.e. it will immediately exit with error status) except
> that the command will print its own error message.

Reasonable things that will do the wrong thing:

count *.c

for i in *.c *.h; ...; end

Also, the error messages are not very helpful in saying what is
wrong with the command:

ls: : No such file or directory

>
> The warning message that you suggest for interactive use could be
> printed regardless - it would just be modified to remove the wording
> that the command will not be executed.

I was thinking that it wouldn't be executed - even in non-interactive
mode. The reasoning was that this is not really an error, only a
warning, and that it might look unprofessional with lots of debug
messages in scripts. I think a better idea is to print these warnings
at debug level 2, and by default not print level 2 debug messages in
non-interactive, but print them in interactive mode. In the distant
future, one could concieve of making the debug level *shudder*
configurable.

>
> [...]
>  > You should obviously rearrange your priorities so that fish is at the
>  > very top. :-)
>
> A quite unexpected response. ;-)

You know you want to!

>
> [..]
> --
> http://members.dodo.com.au/~netocrat
>

-- 
Axel

Resend: Re: [Fish-users] Process substitution workalike now implemented

[Netocrat <net...@do...>]

Axel Liljencrantz wrote:
[...]
 > Bash seems to kill background jobs in command substitutions before
 > they finish, or something similar, while zsh and fish don't. I'd
 > argue that the fish/zsh behaviour has more uses.

Agreed.

[on psub bug when implemented as backgrounded cat to named pipe]
 > Intresting. I can reproduce this bug on one machine, but the code
 > works perfectly on another. (Both machines use Fedora Core 4, the one
 > where this works is much faster and uses nfs)

[...]
 > I'm thinking that perhaps the original tstp implementation has
 > problems caused by buffering of stdin or something like that.

Buffering by fish, the C runtime library or the OS?

 > I am not surprised at finding bugs when doing this, though.
 > Background jobs in command substitutions that write to fifos read by
 > the calling job is definitely a bit of an edge case.

Agreed - as evidenced by bash and zsh behaving differently.

[glibc malloc error messages in fish]
 > Ouch. That is not good at all. I am running fish through Valgrind a
 > lot, to find and identify any memory handling errors. But I'm not
 > finding anything.

Well my fish build includes my conditional array conversion patches with 
which I resolve merge conflicts as they arise, so there's some chance of 
a bug introduced through the resolution process there.

 > On Tue, 18 Oct 2005, Netocrat wrote:
 >> Also I've noticed that filename completion sometimes displays a
 >> messed-up list
[...]
 > This is an old bug, at least a month
 > old, it's even mentioned in the known bugs section.

I didn't check but I see now that it's there.

[...]

>> And I have a suggestion for globbing expansion when the list is empty:
>> expand it to an empty string rather than nothing to prevent this situation:
 >>
 >> fish> ls /usr/nomatch*
 >> [listing of current directory ensues]
 >>
 >> The alternative is what bash does - expand it to the literal wildcard
>> expression - but I seem to recall you being opposed to that which seems
 >> reasonable.
 >
 > The alternative that I like the most is this one:
 >
 > On regular commands, when a wildcard fails to produce matches, the
 > command is not run, and if you are in interactive mode, a warning is
 > written. Something like:
 >
 > fish: The wildcarded string '*.C' did not result in any matches. The
 > command 'ls *.C' will not be executed.

I can't see any problems (except see below) with that as long as it 
doesn't cause output redirection for a pipeline to fail to generate an 
(empty) file which may later be required/tested for:
ls *.c | somecommand > a_file_that_is_later_required_to_be_present

This is mostly relevant to scripts.  Also $status should be set to non-zero.

 > One can configure at runtime that some commands should allow
 > non-matching wildcards,

By fish principles options should be avoided and it's possible to avoid 
them here:

The behaviour of not running the command will - in every case I can 
think of that matters - be identical to running the command with an 
empty string (i.e. it will immediately exit with error status) except 
that the command will print its own error message.

The warning message that you suggest for interactive use could be 
printed regardless - it would just be modified to remove the wording 
that the command will not be executed.

[...]
 > You should obviously rearrange your priorities so that fish is at the
 > very top. :-)

A quite unexpected response. ;-)

[..]
-- 
http://members.dodo.com.au/~netocrat

Re: [Fish-users] Process substitution workalike now implemented

[Axel L. <f9...@na...>]

On Tue, 18 Oct 2005, Netocrat wrote:

[...]
>
> Finally, I've noticed that doing a read from stdin within scripts seems
> to be currently broken:
>
> fish> cat fsh
> #! /usr/local/bin/fish
> cat
> read input
> echo $input
> fish> printf "a\nb\nc\n" > somefile
> fish> ./fsh <somefile
>
> fish>

This is now fixed, and the fix is uploaded to the darcs repository.
The best part about fixing this is that it actually _shortened_ the
source code. A lot of calls to close and duplications of file
descriptors could be removed. The one downside is that the call to
read from a file descriptor is a bit unintuitive in that you pass it
a file descriptor, and if the file descriptor is not 0, then it will
be automatically closed before returning, but if the file descriptor
is 0, it will not be closed. Rather unintuitive call signature, but
it does make the implementation much simpler.

>
> Hunting for and fixing bugs or otherwise contributing to fish's source
> code is a lower priority than other things I'm doing right now, but
> should I take care of those things I may delve into fish's source.
>
> [...]
> --
> http://members.dodo.com.au/~netocrat
>

-- 
Axel

Re: [Fish-users] Process substitution workalike now implemented

[Axel L. <f9...@na...>]

On Tue, 18 Oct 2005, Netocrat wrote:

> Axel Liljencrantz wrote:
> > On Mon, 17 Oct 2005, Netocrat wrote:
> [on psub for process substitution]
> >>As you point out, the above syntax won't support pipes.  It seems to me
> >>that the only way to support pipes is through new tokens as per POSIX.
> >>Perhaps psubin() and psubout() rather than <() and >().
> >
> > Well, it could.
> [...]
> > I initially though using named
> > pipes in the psub function would be hard, since the command
> > substitution won't exit until the program exits, but after a while I
> > realized all one has to do is make the output command a background
> > function, and everything will work perfectly.
>
> Yes, that was my first thought also, and I even tested a function
> identical to your new psub using mkfifo and backgrounded cat.  It didn't
> work all that well and I assumed that when psub exited, fish cut off the
> backgrounded process's input stream.  This seems to be what happens
> under bash in similar circumstances, although it seems to work fine for zsh.

Bash seems to kill background jobs in command substitutions before
they finish, or something similar, while zsh and fish don't. I'd
argue that the fish/zsh behaviour has more uses.

>
> So even though my assumption was apparently incorrect for fish and that
> this implementation is semantically OK after all, there is still a bug
> causing problems - it hangs in certain situations:
>
> fish> cat ~/scratch/fish/tstp
> #! /usr/local/bin/fish
> echo \$1 is $argv[1] and \$2 is $argv[2]
> echo The first line of $argv[1] is:
> read l <$argv[1]
> echo $l
> echo The next line of $argv[1] is:
> read l <$argv[1]
> echo $l
> echo The first line of $argv[2] is:
> read l <$argv[2]
> echo $l
> echo The next line of $argv[2] is:
> read l <$argv[2]
> echo $l
> fish> ~/scratch/fish/tstp (find /data -name "*.c" -exec cat \{\} \;
> ^/dev/null |psub) (cat /data/src-and-projects/patch.fish.* |psub)
> $1 is /tmp/.psub.21779.26977 and $2 is /tmp/.psub.21779.12612
> The first line of /tmp/.psub.21779.26977 is:
> /*
> The next line of /tmp/.psub.21779.26977 is:
>   * Copyright 1999-2005 Gentoo Foundation
> The first line of /tmp/.psub.21779.12612 is:
> diff -uprN /home/netocrat/tmp/fish-1.13.1/init/fish.in
> fish-1.13.1-mod/init/fish.in
> The next line of /tmp/.psub.21779.12612 is:
>
> [at this point the script hangs and I can only terminate it with kill -9]
>
> To confirm that this is a fish problem, running the equivalent bash
> command results in:
> bash$ ~/scratch/fish/tstp <(find /data -name "*.c" -exec cat \{\} \;
> 2>/dev/null) <(cat /data/src-and-projects/patch.fish.*)
> $1 is /dev/fd/63 and $2 is /dev/fd/62
> The first line of /dev/fd/63 is:
> /*
> The next line of /dev/fd/63 is:
>   * Copyright 1999-2005 Gentoo Foundation
> The first line of /dev/fd/62 is:
> diff -uprN /home/netocrat/tmp/fish-1.13.1/init/fish.in
> fish-1.13.1-mod/init/fish.in
> The next line of /dev/fd/62 is:
> --- /home/netocrat/tmp/fish-1.13.1/init/fish.in 2005-08-31
> 20:50:52.000000000 +1000
>
> [at this point the script exits normally; the only difference I notice
> is that output is not as immediate as for fish - presumably bash is
> buffering more]
>
> [...]
> > I'm still optimistic about the psub shellscript function,
>
> Likewise - this problem can probably be identified and solved.

Intresting. I can reproduce this bug on one machine, but the code
works perfectly on another. (Both machines use Fedora Core 4, the one
where this works is much faster and uses nfs)

Even more interesting is that the following implementation of tstp
_does_work, at least for me:

begin
echo \$1 is $argv[1] and \$2 is $argv[2]
echo The first line of $argv[1] is:
read l
echo $l
echo The next line of $argv[1] is:
read l
echo $l
end <$argv[1]

begin
echo The first line of $argv[2] is:
read l
echo $l
echo The next line of $argv[2] is:
read l
echo $l
end <$argv[2]

I'm thinking that perhaps the original tstp implementation has
problems caused by buffering of stdin or something like that. To
check this, I tried the following code:

mkfifo foo1 foo2; find ../.. -name "*.h" -exec cat \{\} \;^/dev/null >foo1 & cat ../*/*.c >foo2 & ./tstp foo1 foo2; rm foo1 foo2

Which hanged in exactly the same way as your original example, but
only with your tstp implementation, not with my alternative
implementation.

I am not surprised at finding bugs when doing this, though.
Background jobs in command substitutions that write to fifos read by
the calling job is definitely a bit of an edge case. But squashing
bugs is a good thing.

>
> I'm coming across a lot of other instability in fish though (I've just
> downloaded the latest five darcs patches but haven't built a new fish
> yet, so this may or may not apply to those patches):
>
> *** glibc detected *** malloc(): memory corruption: 0x08059370 ***
>
> (the above message occurring frequently with no immediately apparent
> untoward effects)

Ouch. That is not good at all. I am running fish through Valgrind a
lot, to find and identify any memory handling errors. But I'm not
finding anything.

>
> Also I've noticed that filename completion sometimes displays a
> messed-up list - part of the command line becomes part of the filename
> prefix.  Next time I come across a repeatable situation I'll post it.

If you mean like

echo function. foo
              ^Cursor is here when <tab is pressed>

generating

nction. fooc   (C source code, 3.0kB)  nction. fooh   (C source code header, 1.7kB)  nction. fooo  (Object code, 9.2kB)
nction. fooc~  (C source code, 2.8kB)  nction. fooh~  (C source code header, 1.6kB)

then I've noticed that too. It is probably some bug in get_param(),
defined in reader.c, line 1098. This is an old bug, at least a month
old, it's even mentioned in the known bugs section. I haven't gotten
round to looking into it, please feel free to do so.

>
> And I have a suggestion for globbing expansion when the list is empty:
> expand it to an empty string rather than nothing to prevent this situation:
>
> fish> ls /usr/nomatch*
> [listing of current directory ensues]
>
> The alternative is what bash does - expand it to the literal wildcard
> expression - but I seem to recall you being opposed to that which seems
> reasonable.

The alternative that I like the most is this one:

On regular commands, when a wildcard fails to produce matches, the
command is not run, and if you are in interactive mode, a warning is
written. Something like:

fish: The wildcarded string '*.C' did not result in any matches. The
command 'ls *.C' will not be executed.

One can configure at runtime that some commands should allow
non-matching wildcards, and this should be preconfigured by the
default fish init files for 'for', and probably a few others as well.

The 'error on umatching wildcard' is what tcsh does, so there is
precedent for this as correct behaviour.

>
> Finally, I've noticed that doing a read from stdin within scripts seems
> to be currently broken:

It is. Fish currently reads the input file through fd 1. Didn't think
about that breaking interactive applications started through
non-interactive scripts when I implemented it. I'll change it.

>
> fish> cat fsh
> #! /usr/local/bin/fish
> cat
> read input
> echo $input
> fish> printf "a\nb\nc\n" > somefile
> fish> ./fsh <somefile
>
> fish>
>
> Hunting for and fixing bugs or otherwise contributing to fish's source
> code is a lower priority than other things I'm doing right now, but
> should I take care of those things I may delve into fish's source.

You should obviously rearrange your priorities so that fish is at the
very top. :-)

Fixes or insights into any fish bugs are of course gratefully
accepted.

>
> [...]
> --
> http://members.dodo.com.au/~netocrat
>
>

-- 
Axel

Re: [Fish-users] Process substitution workalike now implemented

[Netocrat <net...@do...>]

Axel Liljencrantz wrote:
> On Mon, 17 Oct 2005, Netocrat wrote:
[on psub for process substitution]
>>As you point out, the above syntax won't support pipes.  It seems to me
>>that the only way to support pipes is through new tokens as per POSIX.
>>Perhaps psubin() and psubout() rather than <() and >().
> 
> Well, it could.
[...]
> I initially though using named
> pipes in the psub function would be hard, since the command
> substitution won't exit until the program exits, but after a while I
> realized all one has to do is make the output command a background
> function, and everything will work perfectly.

Yes, that was my first thought also, and I even tested a function 
identical to your new psub using mkfifo and backgrounded cat.  It didn't 
work all that well and I assumed that when psub exited, fish cut off the 
backgrounded process's input stream.  This seems to be what happens 
under bash in similar circumstances, although it seems to work fine for zsh.

So even though my assumption was apparently incorrect for fish and that 
this implementation is semantically OK after all, there is still a bug 
causing problems - it hangs in certain situations:

fish> cat ~/scratch/fish/tstp
#! /usr/local/bin/fish
echo \$1 is $argv[1] and \$2 is $argv[2]
echo The first line of $argv[1] is:
read l <$argv[1]
echo $l
echo The next line of $argv[1] is:
read l <$argv[1]
echo $l
echo The first line of $argv[2] is:
read l <$argv[2]
echo $l
echo The next line of $argv[2] is:
read l <$argv[2]
echo $l
fish> ~/scratch/fish/tstp (find /data -name "*.c" -exec cat \{\} \; 
^/dev/null |psub) (cat /data/src-and-projects/patch.fish.* |psub)
$1 is /tmp/.psub.21779.26977 and $2 is /tmp/.psub.21779.12612
The first line of /tmp/.psub.21779.26977 is:
/*
The next line of /tmp/.psub.21779.26977 is:
  * Copyright 1999-2005 Gentoo Foundation
The first line of /tmp/.psub.21779.12612 is:
diff -uprN /home/netocrat/tmp/fish-1.13.1/init/fish.in 
fish-1.13.1-mod/init/fish.in
The next line of /tmp/.psub.21779.12612 is:

[at this point the script hangs and I can only terminate it with kill -9]

To confirm that this is a fish problem, running the equivalent bash 
command results in:
bash$ ~/scratch/fish/tstp <(find /data -name "*.c" -exec cat \{\} \; 
2>/dev/null) <(cat /data/src-and-projects/patch.fish.*)
$1 is /dev/fd/63 and $2 is /dev/fd/62
The first line of /dev/fd/63 is:
/*
The next line of /dev/fd/63 is:
  * Copyright 1999-2005 Gentoo Foundation
The first line of /dev/fd/62 is:
diff -uprN /home/netocrat/tmp/fish-1.13.1/init/fish.in 
fish-1.13.1-mod/init/fish.in
The next line of /dev/fd/62 is:
--- /home/netocrat/tmp/fish-1.13.1/init/fish.in 2005-08-31 
20:50:52.000000000 +1000

[at this point the script exits normally; the only difference I notice 
is that output is not as immediate as for fish - presumably bash is 
buffering more]

[...]
> I'm still optimistic about the psub shellscript function, 

Likewise - this problem can probably be identified and solved.

I'm coming across a lot of other instability in fish though (I've just 
downloaded the latest five darcs patches but haven't built a new fish 
yet, so this may or may not apply to those patches):

*** glibc detected *** malloc(): memory corruption: 0x08059370 ***

(the above message occurring frequently with no immediately apparent 
untoward effects)

Also I've noticed that filename completion sometimes displays a 
messed-up list - part of the command line becomes part of the filename 
prefix.  Next time I come across a repeatable situation I'll post it.

And I have a suggestion for globbing expansion when the list is empty: 
expand it to an empty string rather than nothing to prevent this situation:

fish> ls /usr/nomatch*
[listing of current directory ensues]

The alternative is what bash does - expand it to the literal wildcard 
expression - but I seem to recall you being opposed to that which seems 
reasonable.

Finally, I've noticed that doing a read from stdin within scripts seems 
to be currently broken:

fish> cat fsh
#! /usr/local/bin/fish
cat
read input
echo $input
fish> printf "a\nb\nc\n" > somefile
fish> ./fsh <somefile

fish>

Hunting for and fixing bugs or otherwise contributing to fish's source 
code is a lower priority than other things I'm doing right now, but 
should I take care of those things I may delve into fish's source.

[...]
-- 
http://members.dodo.com.au/~netocrat

Re: [Fish-users] Process substitution workalike now implemented

[Axel L. <f9...@na...>]

On Mon, 17 Oct 2005, Netocrat wrote:

> Axel Liljencrantz wrote:
> >
> > The darcs repository now has a working proof of concept for a process
> > substitution workalike shellscript function.
> >
> > Usage:
> >
> >>diff (whatever|psub) (somethingorother|psub) --brief
> >
> > Files /tmp/.psub.5945.4473 and /tmp/.psub.5945.31329 differ
> [...]
> > It uses a temporary file instead of a named pipe, since writing to a
> > named pipe would block on large output. This is a bit inefficient,
> > since the data might be forced to land on disk.
>
> One of the main benefits of pipes is that it's not necessary to wait for
> a process to complete before starting to use its output.  Also that even
> when the output is huge or ongoing, running out of disk space is not an
> issue.
>
> As you point out, the above syntax won't support pipes.  It seems to me
> that the only way to support pipes is through new tokens as per POSIX.
> Perhaps psubin() and psubout() rather than <() and >().


Well, it could.

foo <(bar)

is pretty much equivalent to

foo (mkfifo /tmp/WHATEVER; function --on-exit caller WHATEVER2; rm /tmp/WHATEVER; functions -e WHATEVER2; end; bar > /tmp/WHATEVER &)

That has version has no drawbacks, it uses exactly the same kernel
objects as bash process substitution. I initially though using named
pipes in the psub function would be hard, since the command
substitution won't exit until the program exits, but after a while I
realized all one has to do is make the output command a background
function, and everything will work perfectly.

The new psub implementation:

function psub -d "Read from stdin into a file and output the filename. Remove the file when the command that calles psub exits."

    if not status --is-command-substitution
        echo psub: Not inside of command substitution
        return
    end

    # Find unique file name for writing output to
    while true
        set filename /tmp/.psub.(echo %self).(random);
        if not test -e $filename
            break;
        end
    end

    # Write output to pipe
    mkfifo $filename
    cat >$filename &

    # Write filename to stdout
    echo $filename

    # Find unique function name
    while true
        set funcname __fish_psub_(random);
        if not functions $funcname >/dev/null ^/dev/null
            break;
        end
    end

    # Make sure we erase file when caller exits
    eval function $funcname --on-job-exit caller\; rm $filename\; functions -e $funcname\; end

end

I've done some tests, and it works asynchronously with no problems.
The only performance penalty here is the piping through cat, which
should be very nearly neglectible in all but the most contrived
cases.


>
> These would need to be builtins similar to command substitution since
> the parentheses enclose arbitrary commands, however I know you wanted to
> avoid a new builtin.
>
> So if you still oppose new builtin(s), IMO this function should be
> renamed to make it clear that it is not a true process substitution but
> rather a shortcut for using temporary files.  Users would then write
> ad-hoc code for named pipes.
>
> The other possibility of making psub a function/builtin without
> enclosing parentheses seems problematic (non-functional command follows):
>
> diff (psubin whatever|somethingelse) (psubin while testcmd;
> somethingorother; end)
>
> The special meaning of the pipe symbol and semicolons must be escaped,
> either using backslash or quoting.  This would make syntax highlighting
> harder and would be unintuitive.

I'm still optimistic about the psub shellscript function, but if need
be, I think you are right that adding a psub builtin is probably the
best way to go.

>
> --
> http://members.dodo.com.au/~netocrat
>

-- 
Axel

Re: [Fish-users] New builtin: ulimit

[Axel L. <f9...@na...>]

On Mon, 17 Oct 2005, Claes N=E4st=E9n wrote:

> Axel Liljencrantz wrote:
>
> > Applied. Thanks!
> >
> Sorry, incorrect configure.ac patch, with typos and everything. :/
>
> Fix that should make it work just fine, don't forget to run autoheader
> though.

Doh, my bad. I tested your patch and it worked on my machine, but I
forgot to run autoconf. I'll add this asap.

>
> --
> Claes N=E4st=E9n, <me{@}pekdon{.}net>, http://pekdon.net/
>
>

--=20
Axel

Re: [Fish-users] New builtin: ulimit

[<me...@pe...>]

Axel Liljencrantz wrote:

> Applied. Thanks!
>
Sorry, incorrect configure.ac patch, with typos and everything. :/

Fix that should make it work just fine, don't forget to run autoheader
though.

--=20
Claes N=E4st=E9n, <me{@}pekdon{.}net>, http://pekdon.net/

Re: [Fish-users] Process substitution workalike now implemented

[Netocrat <net...@do...>]

Axel Liljencrantz wrote:
> 
> The darcs repository now has a working proof of concept for a process
> substitution workalike shellscript function.
> 
> Usage:
> 
>>diff (whatever|psub) (somethingorother|psub) --brief
> 
> Files /tmp/.psub.5945.4473 and /tmp/.psub.5945.31329 differ
[...]
> It uses a temporary file instead of a named pipe, since writing to a
> named pipe would block on large output. This is a bit inefficient,
> since the data might be forced to land on disk.

One of the main benefits of pipes is that it's not necessary to wait for 
a process to complete before starting to use its output.  Also that even 
when the output is huge or ongoing, running out of disk space is not an 
issue.

As you point out, the above syntax won't support pipes.  It seems to me 
that the only way to support pipes is through new tokens as per POSIX. 
Perhaps psubin() and psubout() rather than <() and >().

These would need to be builtins similar to command substitution since 
the parentheses enclose arbitrary commands, however I know you wanted to 
avoid a new builtin.

So if you still oppose new builtin(s), IMO this function should be 
renamed to make it clear that it is not a true process substitution but 
rather a shortcut for using temporary files.  Users would then write 
ad-hoc code for named pipes.

The other possibility of making psub a function/builtin without 
enclosing parentheses seems problematic (non-functional command follows):

diff (psubin whatever|somethingelse) (psubin while testcmd; 
somethingorother; end)

The special meaning of the pipe symbol and semicolons must be escaped, 
either using backslash or quoting.  This would make syntax highlighting 
harder and would be unintuitive.

-- 
http://members.dodo.com.au/~netocrat

Re: [Fish-users] New builtin: ulimit

[Axel L. <f9...@na...>]

On Sun, 16 Oct 2005, Claes [unknown-8bit] N=C3=A4st=C3=A9n wrote:

> On Sat, Oct 15, 2005 at 12:44:03AM +0200, Axel Liljencrantz wrote:
> >
> > I've implemented the bash builtin 'ulimit'.
> >
>
> RLIMIT_AS seems not to be available on NetBSD 2.1-RC5, so applied is a
> patch that adds checks for RTLIMIT_AS in sys/resource.h and leavs out
> the -v option if RLIMIT_AS is available. The patch also adds a
> missing include of "config.h" env_universal.c which was forcing the use
> of the curses.h header.

Applied. Thanks!

>
> --
> Claes N=C3=A4st=C3=A9n, <me{@}pekdon{.}net>, http://pekdon.net/
>

--=20
Axel

Re: [Fish-users] New builtin: ulimit

[Claes <me...@pe...>]

On Sat, Oct 15, 2005 at 12:44:03AM +0200, Axel Liljencrantz wrote:
>=20
> I've implemented the bash builtin 'ulimit'.
>=20

RLIMIT_AS seems not to be available on NetBSD 2.1-RC5, so applied is a
patch that adds checks for RTLIMIT_AS in sys/resource.h and leavs out
the -v option if RLIMIT_AS is available. The patch also adds a
missing include of "config.h" env_universal.c which was forcing the use
of the curses.h header.

--=20
Claes N=C3=A4st=C3=A9n, <me{@}pekdon{.}net>, http://pekdon.net/

Re: [Fish-users] New builtin: ulimit

[Axel L. <f9...@na...>]

On Sat, 15 Oct 2005, Netocrat wrote:

> Axel Liljencrantz wrote:
> [...]
> > Changes are in the darcs repository.
>
> make: *** No rule to make target `doc_src/ulimit.txt', needed by
> `doc_src/ulimit.doxygen'.  Stop.


Oops. Fixed.


>
> --
> http://members.dodo.com.au/~netocrat
>
-- 
Axel

Re: [Fish-users] New builtin: ulimit

[Netocrat <net...@do...>]

Axel Liljencrantz wrote:
[...]
> Changes are in the darcs repository.

make: *** No rule to make target `doc_src/ulimit.txt', needed by 
`doc_src/ulimit.doxygen'.  Stop.

-- 
http://members.dodo.com.au/~netocrat

[Fish-users] Process substitution workalike now implemented

[Axel L. <f9...@na...>]

The darcs repository now has a working proof of concept for a process
substitution workalike shellscript function.

Usage:

> diff (whatever|psub) (somethingorother|psub) --brief
Files /tmp/.psub.5945.4473 and /tmp/.psub.5945.31329 differ


The psub function looks like this:

function psub

    if not status --is-command-substitution
        echo psub: Not inside of command substitution
    end

    # Find unique file name ($filename)
    ....


    # Find unique function name ($funcname)
    ...


    cat >$filename

    eval function $funcname --on-job-exit caller\; rm $filename\; functions -e $funcname\; end

    echo $filename

end

It uses a temporary file instead of a named pipe, since writing to a
named pipe would block on large output. This is a bit inefficient,
since the data might be forced to land on disk. Also, the generated
filenames and function names might have issues if one uses process
substitution inside of event handlers, since fish doesn't support any
blocking yet.

-- 
Axel

[Fish-users] New builtin: ulimit

[Axel L. <f9...@na...>]

I've implemented the bash builtin 'ulimit'.

The fish implementation of ulimit should behave identically to the
implementation in bash, except for these differences:

* Fish ulimit supports GNU-style long options for all switches
* Fish ulimit does not support the -p option for getting the pipe
size. The bash implementation consists of a compile-time check that
empirically guesses this number by writing to a pipe and waiting for
SIGPIPE.
* Fish ulimit does not support getting the values of multiple limits
in one command, except by using the -a switch

Also, it seems that there is a bit of undocumented behaviour in
ulimit, for example there is a -q switch, and it is possible to set
all limits, etc. I mostly tried to do the same thing the ulimit
command does, not what the documentation says it does.

I'm kind of surprised by the bash implementation of the -p switch. It
has at least the following issues:

* May break if bash is compiled and run on different systems, i.e all
precompiled packages may break
* May break on kernel or libc upgrades
* Is implementation dependant
* Only works if the pipe size is a multiple of 128, since that is
how many bytes are written at a time

Given the number of problems with -p, I though it was a much better
idea to leave it unimplemented.

Changes are in the darcs repository. There are also patches to make
signal blocking a bit more robust, as well as nice automatic
linebreaking for the debug function.

-- 
Axel