Re: feature request: file_not_found_handle()
Hi. > Date: Tue, 20 Aug 2013 11:02:24 -0400 > From: Greg Wooledge > To: Aharon Robbins > Cc: bug-bash@gnu.org > Subject: Re: feature request: file_not_found_handle() > > On Tue, Aug 20, 2013 at 05:48:12PM +0300, Aharon Robbins wrote: > > In article you write: > > >1) PATH is used by the kernel (exec family) to determine how commands are > > > executed. The way PATH is used by the kernel is not likely to change. > > > Having the shell treat it differently would lead to confusion. > > > > Actually, PATH searching is implemented in the C library and always > > has been; there is only one real system call. The confusion likely arises > > from the traditional practice of documenting all the exec calls on the > > same manpage. > > Oh, really? That's very misleading and confusing. > > HP-UX 10.20 exec(2) says: > > The exec*() system calls, in all their forms, ... > > So that's a complete lie, I guess. A small fiction. The man pages were that way since at least V7, and probably further back. IIRC the BSD folks at 4.2 left execve in section 2 and moved the rest to section 3. It is certianly that way now on GNU/Linux systems. > (And they do appear to be defined in > /lib/libc.a if I'm reading the output of nm correctly.) All the system calls are in /lib/libc.a. They are implemented as regular C wrappers around a special function (usually) written in assembly that traps into the kernel passing the system call number and the parameters and returning the result code. On a Linux system see syscalls(2), syscall(2) and possibly _syscall(2) (the latter is marked obsolete). As Chet said, most people don't really need to know about this fiction. Thanks, Arnold
Empty trailing fields ignored by read
When using a non-default IFS (a default IFS would trim them), a single
empty trailing field is ignored for read -a.
IFS=: read -rd '' -a arr < <(printf %s ':foo:bar:'); printf '<%s> '
"${arr[@]}"; echo
<>
I would expect the output to be:
<> <>
Re: Empty trailing fields ignored by read
On Thu, Aug 29, 2013 at 12:42 PM, DJ Mills wrote:
> When using a non-default IFS (a default IFS would trim them), a single
> empty trailing field is ignored for read -a.
>
> IFS=: read -rd '' -a arr < <(printf %s ':foo:bar:'); printf '<%s> '
> "${arr[@]}"; echo
> <>
>
> I would expect the output to be:
> <> <>
>
By the way, this is on 4.2.45(2)-release, but it also occurs on
4.2.45(1)-release and 3.2.51(1)-release.
A workaround is to use < <(printf %s: "$foo"), but that shouldn't be needed.
Lack of quotes causes IFS to be ignored for "${arr[*]}" during assignments
$(arr=(foo bar baz); IFS=:; str=${arr[*]}; echo "$str")
foo bar baz
$ (arr=(foo bar baz); IFS=:; str="${arr[*]}"; echo "$str")
foo:bar:baz
Note that the same thing does not occur for "$*":
$ (set -- foo bar baz; IFS=:; str=$*; echo "$str")
foo:bar:baz
$ (set -- foo bar baz; IFS=:; str="$*"; echo "$str")
foo:bar:baz
I would expect the behavior of the two to be identical.
$ echo "$BASH_VERSION"
4.2.45(2)-release
It also occurs in 4.2.45(1)-release and 3.2.51(1)-release.
Re: Lack of quotes causes IFS to be ignored for "${arr[*]}" during assignments
On Thursday, August 29, 2013 01:03:20 PM DJ Mills wrote:
> $(arr=(foo bar baz); IFS=:; str=${arr[*]}; echo "$str")
> foo bar baz
> $ (arr=(foo bar baz); IFS=:; str="${arr[*]}"; echo "$str")
> foo:bar:baz
>
> Note that the same thing does not occur for "$*":
> $ (set -- foo bar baz; IFS=:; str=$*; echo "$str")
> foo:bar:baz
> $ (set -- foo bar baz; IFS=:; str="$*"; echo "$str")
> foo:bar:baz
>
> I would expect the behavior of the two to be identical.
>
> $ echo "$BASH_VERSION"
> 4.2.45(2)-release
>
> It also occurs in 4.2.45(1)-release and 3.2.51(1)-release.
This was this issue:
http://gnu-bash.2382.n7.nabble.com/More-fun-with-IFS-td11388.html
The assignments are all consistent in 4.3.
https://gist.github.com/ormaaj/6381747
--
Dan Douglas
Re: Empty trailing fields ignored by read
On Thu, Aug 29, 2013 at 12:57:22PM -0400, DJ Mills wrote:
> On Thu, Aug 29, 2013 at 12:42 PM, DJ Mills wrote:
>
> > When using a non-default IFS (a default IFS would trim them), a single
> > empty trailing field is ignored for read -a.
> >
> > IFS=: read -rd '' -a arr < <(printf %s ':foo:bar:'); printf '<%s> '
> > "${arr[@]}"; echo
> > <>
> >
> > I would expect the output to be:
> > <> <>
Looks like:
http://lists.gnu.org/archive/html/bug-bash/2008-02/msg00056.html
There may be other occurrences. I seem to recall something more recent
than 2008.
Re: Lack of quotes causes IFS to be ignored for "${arr[*]}" during assignments
On Thu, Aug 29, 2013 at 2:38 PM, Dan Douglas wrote:
> On Thursday, August 29, 2013 01:03:20 PM DJ Mills wrote:
> > $(arr=(foo bar baz); IFS=:; str=${arr[*]}; echo "$str")
> > foo bar baz
> > $ (arr=(foo bar baz); IFS=:; str="${arr[*]}"; echo "$str")
> > foo:bar:baz
> >
> > Note that the same thing does not occur for "$*":
> > $ (set -- foo bar baz; IFS=:; str=$*; echo "$str")
> > foo:bar:baz
> > $ (set -- foo bar baz; IFS=:; str="$*"; echo "$str")
> > foo:bar:baz
> >
> > I would expect the behavior of the two to be identical.
> >
> > $ echo "$BASH_VERSION"
> > 4.2.45(2)-release
> >
> > It also occurs in 4.2.45(1)-release and 3.2.51(1)-release.
>
> This was this issue:
> http://gnu-bash.2382.n7.nabble.com/More-fun-with-IFS-td11388.html
>
> The assignments are all consistent in 4.3.
>
> https://gist.github.com/ormaaj/6381747
> --
> Dan Douglas
Gotcha, thanks
Re: Empty trailing fields ignored by read
On Thu, Aug 29, 2013 at 2:54 PM, Greg Wooledge wrote:
> On Thu, Aug 29, 2013 at 12:57:22PM -0400, DJ Mills wrote:
> > On Thu, Aug 29, 2013 at 12:42 PM, DJ Mills
> wrote:
> >
> > > When using a non-default IFS (a default IFS would trim them), a single
> > > empty trailing field is ignored for read -a.
> > >
> > > IFS=: read -rd '' -a arr < <(printf %s ':foo:bar:'); printf '<%s> '
> > > "${arr[@]}"; echo
> > > <>
> > >
> > > I would expect the output to be:
> > > <> <>
>
> Looks like:
> http://lists.gnu.org/archive/html/bug-bash/2008-02/msg00056.html
>
> There may be other occurrences. I seem to recall something more recent
> than 2008.
>
That's a different issue, and in that case makes sense. It's the same
reason that
when reading a file with no trailing newline, read will exit > 0 for the
last line.
In this case, the exit status is irrelevant. In fact, I expect it to exit >
0, as there's no
NUL byte in the input. However, with or without -d, the last field is
completely ignored.
