* trapped in bash
@ 2016-12-16 15:33 Ray Andrews
2016-12-16 21:51 ` Aaron Schrab
2016-12-17 23:16 ` Jim
0 siblings, 2 replies; 17+ messages in thread
From: Ray Andrews @ 2016-12-16 15:33 UTC (permalink / raw)
To: Zsh Users
So I'm setting up a new machine with Debian 64 (using Debian 32 still on
old machine) and I'm thinking to just copy over my whole zsh install
from here to there and ... nope ... I 'cd' to where the binary is and
type 'zsh' and bash reports that it can't find the file. Copy it to
'/bin' and it still can't find it. Even the desperate '. ./zsh' reports
'cannot execute binary file'. I hope to gawd that an apt-get install of
zsh would work, but I'd like to use my existing setup exactly as is. Do
I have to rebuild? I'm new with 64 bit issues, whatever they may happen
to be, but I thought a 64 bit environment could always run 32 bit apps.
Or have I forgotten something simple? Meanwhile I'm trapped in the
pre-fire age of bash out of the box. Even 'ls -l' doesn't work,
filenames only. They say that suffering purifies the soul ;-)
BTW:
_array=( ${(f)_variable} )
_count=$#_array # Count the number of lines.
Can that be simplified? I don't need the _array, just the _count. Of
course there are any number of utilities to count lines, but I mean the
simplest zsh way, although the above is nicely self-explanatory.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-16 15:33 trapped in bash Ray Andrews
@ 2016-12-16 21:51 ` Aaron Schrab
2016-12-16 22:39 ` Ray Andrews
2016-12-17 23:16 ` Jim
1 sibling, 1 reply; 17+ messages in thread
From: Aaron Schrab @ 2016-12-16 21:51 UTC (permalink / raw)
To: Ray Andrews; +Cc: Zsh Users
At 07:33 -0800 16 Dec 2016, Ray Andrews <rayandrews@eastlink.ca> wrote:
>So I'm setting up a new machine with Debian 64 (using Debian 32 still
>on old machine) and I'm thinking to just copy over my whole zsh
>install from here to there and ... nope ... I 'cd' to where the binary
>is and type 'zsh' and bash reports that it can't find the file. Copy
>it to '/bin' and it still can't find it. Even the desperate '. ./zsh'
>reports 'cannot execute binary file'. I hope to gawd that an apt-get
>install of zsh would work, but I'd like to use my existing setup
>exactly as is. Do I have to rebuild? I'm new with 64 bit issues,
>whatever they may happen to be, but I thought a 64 bit environment
>could always run 32 bit apps. Or have I forgotten something simple?
The hardware and kernel are able to run 32bit binaries, but you can't
use 64bit shared libraries with 32bit executables (or vice-versa). You
also need the 32bit version of the run-time dynamic linker; lack of that
is why you're being told that a file isn't found.
Unless there was something really special about that build I'd either
just go with installing via apt or rebuilding.
If you *really* want to use the same build you can likely do that with a
multi-arch setup. To start with that would involve:
dpkg --add-architecture i386
apt update
apt install libc6:i386
Once that is done the system should at least recognize that the old zsh
build is executable. But you'll likely need to install several other
i386 libraries; depending on the age of the system where that was built
it's possible that the required versions won't be found for the current
version of Debian.
The number of i386 library packages needed for this shouldn't be large,
but a multi-arch system does mean that every `apt update` will fetch the
package list for both of the architectures.
>Meanwhile I'm trapped in the pre-fire age of bash out of the box.
>Even 'ls -l' doesn't work, filenames only.
That shouldn't have anything to do with bash vs. zsh.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-16 21:51 ` Aaron Schrab
@ 2016-12-16 22:39 ` Ray Andrews
2016-12-16 23:05 ` Bart Schaefer
0 siblings, 1 reply; 17+ messages in thread
From: Ray Andrews @ 2016-12-16 22:39 UTC (permalink / raw)
To: Zsh Users
On 12/16/2016 01:51 PM, Aaron Schrab wrote:
> The hardware and kernel are able to run 32bit binaries, but you can't
> use 64bit shared libraries with 32bit executables (or vice-versa).
> You also need the 32bit version of the run-time dynamic linker; lack
> of that is why you're being told that a file isn't found.
>
> Unless there was something really special about that build I'd either
> just go with installing via apt or rebuilding.
>
Thanks Aaron. No, I've no reason not to rebuild I just wondered about
the 'not found' thing, it seems like an unhelpful message. What you say
doesn't surprise me as to the libraries. It is almost comical how
helpless I am with out zsh now -- I can't install it for lack of having
it. I'll use apt-get and then go from there.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-16 22:39 ` Ray Andrews
@ 2016-12-16 23:05 ` Bart Schaefer
2016-12-17 20:27 ` Ray Andrews
0 siblings, 1 reply; 17+ messages in thread
From: Bart Schaefer @ 2016-12-16 23:05 UTC (permalink / raw)
To: Ray Andrews, Zsh Users
On Dec 16, 2:39pm, Ray Andrews wrote:
}
} I've no reason not to rebuild I just wondered about
} the 'not found' thing, it seems like an unhelpful message.
Agreed, it's very unhelpful/baffling, because what's not found is
not the binary itself, but one of the libraries needed to load it.
Sadly, the calling shell can't tell the difference, because all it
gets back is a numeric error code from the execve() system call.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-16 23:05 ` Bart Schaefer
@ 2016-12-17 20:27 ` Ray Andrews
2016-12-17 20:43 ` Bart Schaefer
0 siblings, 1 reply; 17+ messages in thread
From: Ray Andrews @ 2016-12-17 20:27 UTC (permalink / raw)
To: zsh-users
On 12/16/2016 03:05 PM, Bart Schaefer wrote:
> On Dec 16, 2:39pm, Ray Andrews wrote:
> }
> } I've no reason not to rebuild I just wondered about
> } the 'not found' thing, it seems like an unhelpful message.
Agreed, it's very unhelpful/baffling, because what's not found is not
the binary itself, but one of the libraries needed to load it. Sadly,
the calling shell can't tell the difference, because all it gets back is
a numeric error code from the execve() system call.
Seems I have to rebuild all my own C projects as they have the same
'not found' characteristic.
One little anomaly , the zsh right now is via the package manager in
Debian: "zsh 5.2 (x86_64-debian-linux-gnu)" and I source my usual .zshrc
and so far everything is where I put it, except that command completion,
if there is no match, brings up the last command, whereas my setup
should do nothing (leave the prompt blank). Where might that change be
effected from?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-17 20:27 ` Ray Andrews
@ 2016-12-17 20:43 ` Bart Schaefer
2016-12-17 22:40 ` Ray Andrews
[not found] ` <5855BEF2.6090208__18199.534857604$1482015164$gmane$org@eastlink.ca>
0 siblings, 2 replies; 17+ messages in thread
From: Bart Schaefer @ 2016-12-17 20:43 UTC (permalink / raw)
To: Ray Andrews, zsh-users
On Dec 17, 12:27pm, Ray Andrews wrote:
}
} Seems I have to rebuild all my own C projects as they have the same
} 'not found' characteristic.
Or you need to follow Aaron's instructions for installing the 32-bit
runtime on your 64-bit system. Although that's not *guaranteed* to
make everything work without rebuilding.
} and so far everything is where I put it, except that command completion,
} if there is no match, brings up the last command, whereas my setup
} should do nothing (leave the prompt blank). Where might that change be
} effected from?
That doesn't sound familiar at all. Bringing up the last command seems
to imply that one of the history completers is in the zstyle.
Your best bet may be:
1. type ctrl-x h and see what completions are active in that context;
2. if that doesn't give you an obvious hint, use ctrl-x ? for a debug
trace and look through that.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-17 20:43 ` Bart Schaefer
@ 2016-12-17 22:40 ` Ray Andrews
[not found] ` <5855BEF2.6090208__18199.534857604$1482015164$gmane$org@eastlink.ca>
1 sibling, 0 replies; 17+ messages in thread
From: Ray Andrews @ 2016-12-17 22:40 UTC (permalink / raw)
To: Bart Schaefer, zsh-users
On 12/17/2016 12:43 PM, Bart Schaefer wrote:
> On Dec 17, 12:27pm, Ray Andrews wrote:
> }
> } Seems I have to rebuild all my own C projects as they have the same
> } 'not found' characteristic.
>
> Or you need to follow Aaron's instructions for installing the 32-bit
> runtime on your 64-bit system. Although that's not *guaranteed* to
> make everything work without rebuilding.
No need to risk doing something that might be flaky, I'm just rebuilding
as needed. So far there hasn't been a hint of a problem beyond needing
to retrieve some 64 bit libraries. So I'm pumped that zsh will rebuild
with similar results.
>
> } and so far everything is where I put it, except that command completion,
> } if there is no match, brings up the last command, whereas my setup
> } should do nothing (leave the prompt blank). Where might that change be
> } effected from?
>
> That doesn't sound familiar at all. Bringing up the last command seems
> to imply that one of the history completers is in the zstyle.
>
> Your best bet may be:
>
> 1. type ctrl-x h and see what completions are active in that context;
>
> 2. if that doesn't give you an obvious hint, use ctrl-x ? for a debug
> trace and look through that.
>
>
Ah ... it's the stock files in /etc/zsh, I renamed the directory and
everything is as I expect. It's one of my perpetual mini-rants to hate
the way most linux programs hide bits of themselves all over the place.
Actually I deleted all those on my main machine for fear of them
doing funny things on Tuesday, but it's time I took a look at them again
and put them work, maybe, now that I have some clue what I'm doing.
Thanks Bart.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-16 15:33 trapped in bash Ray Andrews
2016-12-16 21:51 ` Aaron Schrab
@ 2016-12-17 23:16 ` Jim
2016-12-17 23:38 ` Ray Andrews
1 sibling, 1 reply; 17+ messages in thread
From: Jim @ 2016-12-17 23:16 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
On Fri, Dec 16, 2016 at 9:33 AM, Ray Andrews <rayandrews@eastlink.ca>
wrote:
>
> BTW:
>
> _array=( ${(f)_variable} )
> _count=$#_array # Count the number of lines.
>
> Can that be simplified? I don't need the _array, just the _count. Of
> course there are any number of utilities to count lines, but I mean the
> simplest zsh way, although the above is nicely self-explanatory
_count=${#${(f)_variable}}
This will remove the need for the variable _array. One caution, if your
not already aware, (f) removes blank lines, so they won't show up in
the count.
Hope this helps,
Jim
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-17 23:16 ` Jim
@ 2016-12-17 23:38 ` Ray Andrews
0 siblings, 0 replies; 17+ messages in thread
From: Ray Andrews @ 2016-12-17 23:38 UTC (permalink / raw)
To: zsh-users
On 12/17/2016 03:16 PM, Jim wrote:
>
>
> _count=${#${(f)_variable}}
>
> This will remove the need for the variable _array. One caution, if your
> not already aware, (f) removes blank lines, so they won't show up in
> the count.
>
> Hope this helps,
>
> Jim
>
Thanks Jim, my experiments failed 'cuz I insisted on including the
parenthesis, but since no array is created, no parenthesis are needed.
Clear in hindsight.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
[not found] ` <5855BEF2.6090208__18199.534857604$1482015164$gmane$org@eastlink.ca>
@ 2016-12-18 15:06 ` Daniel Shahaf
2016-12-18 15:54 ` Ray Andrews
0 siblings, 1 reply; 17+ messages in thread
From: Daniel Shahaf @ 2016-12-18 15:06 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
Ray Andrews wrote on Sat, Dec 17, 2016 at 14:40:50 -0800:
> Ah ... it's the stock files in /etc/zsh, I renamed the directory and
> everything is as I expect.
If you just rename the directory, it'll be recreated the next time you
upgrade your zsh package (which is probably very soon). You could
instead 'setopt NO_GLOBAL_RCS' in .zshenv.
dpkg-divert(1) may work as well (I'm not sure how it handles directory
diversions).
Cheers,
Daniel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-18 15:06 ` Daniel Shahaf
@ 2016-12-18 15:54 ` Ray Andrews
2016-12-19 0:32 ` Daniel Shahaf
0 siblings, 1 reply; 17+ messages in thread
From: Ray Andrews @ 2016-12-18 15:54 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: zsh-users
On 12/18/2016 07:06 AM, Daniel Shahaf wrote:
> Ray Andrews wrote on Sat, Dec 17, 2016 at 14:40:50 -0800:
>> Ah ... it's the stock files in /etc/zsh, I renamed the directory and
>> everything is as I expect.
> If you just rename the directory, it'll be recreated the next time you
> upgrade your zsh package (which is probably very soon).
Sure, that's to be expected.
> You could
> instead 'setopt NO_GLOBAL_RCS' in .zshenv.
I'll look into that, thanks. Meanwhile just shooting the directory was
easy enough to understand. But as I said I want to take a look at those
half a dozen various ifs ands buts and maybes as to the startup files,
right now one plain old .zshrc seems to do everything nicely however.
BTW, as to the 'file not found' thing last time, not that this is worth
any bother, but surely the shell knows that it has found its target file
vs. not being able to run it for some secondary reason? zsh and bash
seem to have the same message there, as I found trying to start zsh
from bash, or any of my 32 bit binaries from zsh under 64 bit Debian.
Would it be doable to distinguish between *really* 'not found' and
'can't run this binary'? If nothing else it would have stopped me from
having to ask that question :-/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-18 15:54 ` Ray Andrews
@ 2016-12-19 0:32 ` Daniel Shahaf
2016-12-19 2:30 ` Bart Schaefer
0 siblings, 1 reply; 17+ messages in thread
From: Daniel Shahaf @ 2016-12-19 0:32 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
Ray Andrews wrote on Sun, Dec 18, 2016 at 07:54:27 -0800:
> Would it be doable to distinguish between *really* 'not found' and
> 'can't run this binary'? If nothing else it would have stopped me
> from having to ask that question :-/
As far as zsh is concerned, a binary file is simply something that can
be passed to execve(). zsh does not attempt to parse or load the file;
the C library and OS do. So it is they who are in a position to issue
an error message explaining _why_ the file can't be executed.
I suppose you could write a command_not_found_handler() function that
tried to reverse engineer _why_ the command wasn't found — with the
obvious limitations, e.g., race conditions between the library's
execution and the handler's.
Cheers,
Daniel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-19 0:32 ` Daniel Shahaf
@ 2016-12-19 2:30 ` Bart Schaefer
2016-12-19 4:29 ` Ray Andrews
0 siblings, 1 reply; 17+ messages in thread
From: Bart Schaefer @ 2016-12-19 2:30 UTC (permalink / raw)
To: zsh-users
On Dec 19, 12:32am, Daniel Shahaf wrote:
}
} I suppose you could write a command_not_found_handler() function that
} tried to reverse engineer _why_ the command wasn't found - with the
} obvious limitations, e.g., race conditions between the library's
} execution and the handler's.
I don't think there can be a race here because the handler won't be
invoked if the execve() hasn't already failed.
Something like this:
command_not_found_handler () {
local attempt="$1"
if [[ "$1" != /* && ( -o pathdirs || "$1
" != */* ) ]]
then
emulate zsh -c 'attempt=$^path/$1(N[1])'
fi
if [[ -f $attempt ]]
then
local hashbang
read -u 0 -k 2 hashbang < "$attempt"
case "$hashbang" in
('#!') print -u2 -- $1\: bad '#!' interpreter ;;
(*) print -u2 failed to load $1 ;;
esac
else
print -u2 -- $1\: no such file in \$PATH
fi
return 127
}
--
Barton E. Schaefer
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-19 2:30 ` Bart Schaefer
@ 2016-12-19 4:29 ` Ray Andrews
2016-12-19 5:48 ` Bart Schaefer
0 siblings, 1 reply; 17+ messages in thread
From: Ray Andrews @ 2016-12-19 4:29 UTC (permalink / raw)
To: zsh-users
On 18/12/16 06:30 PM, Bart Schaefer wrote:
> On Dec 19, 12:32am, Daniel Shahaf wrote:
> }
> } I suppose you could write a command_not_found_handler() function that
> } tried to reverse engineer _why_ the command wasn't found - with the
> } obvious limitations, e.g., race conditions between the library's
> } execution and the handler's.
>
> I don't think there can be a race here because the handler won't be
> invoked if the execve() hasn't already failed.
>
> Something like this:
>
> command_not_found_handler () {
> local attempt="$1"
> if [[ "$1" != /* && ( -o pathdirs || "$1
> " != */* ) ]]
> then
> emulate zsh -c 'attempt=$^path/$1(N[1])'
> fi
> if [[ -f $attempt ]]
> then
> local hashbang
> read -u 0 -k 2 hashbang < "$attempt"
> case "$hashbang" in
> ('#!') print -u2 -- $1\: bad '#!' interpreter ;;
> (*) print -u2 failed to load $1 ;;
> esac
> else
> print -u2 -- $1\: no such file in \$PATH
> fi
> return 127
> }
>
>
Not for me to say, but it seems to me that the simple fact that a file
exists or does not exist is simple enough to determine in the tradition
of 'whence' or something like that. *Then* we run into issues about
executing it *after* the thing has (obviously) been found. Sometimes a
command can't be found because it can't be found, that is, the file
simply does not exist. Or is that too simple? Anyway I sure like the idea.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-19 4:29 ` Ray Andrews
@ 2016-12-19 5:48 ` Bart Schaefer
2016-12-19 16:26 ` Ray Andrews
[not found] ` <ab7aeb33-d091-6602-8baa-cce92300d289__26556.3400615521$1482166729$gmane$org@eastlink.ca>
0 siblings, 2 replies; 17+ messages in thread
From: Bart Schaefer @ 2016-12-19 5:48 UTC (permalink / raw)
To: zsh-users
On Dec 18, 8:29pm, Ray Andrews wrote:
}
} Not for me to say, but it seems to me that the simple fact that a file
} exists or does not exist is simple enough to determine
Well, yes.
The shell finds the file, because it's responsible for path search.
It then forks, and the child process passes the full path to execve(),
which replaces the child shell with the kernel code that is supposed
to start up the new executable.
That kernel code then fails for whatever reason -- in this case, it's
because the 32-bit library is not found -- and returns a nonzero
numeric exit code to the parent shell.
The parent shell prints the message associated with that error code.
It isn't responsible for guessing what caused the error; there could
for example have been additional rounds of finding and exec'ing other
paths of which the parent has no knowledge, before a final exit.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
2016-12-19 5:48 ` Bart Schaefer
@ 2016-12-19 16:26 ` Ray Andrews
[not found] ` <ab7aeb33-d091-6602-8baa-cce92300d289__26556.3400615521$1482166729$gmane$org@eastlink.ca>
1 sibling, 0 replies; 17+ messages in thread
From: Ray Andrews @ 2016-12-19 16:26 UTC (permalink / raw)
To: zsh-users
On 18/12/16 09:48 PM, Bart Schaefer wrote:
> On Dec 18, 8:29pm, Ray Andrews wrote:
> }
> } Not for me to say, but it seems to me that the simple fact that a file
> } exists or does not exist is simple enough to determine
>
> Well, yes.
>
> The shell finds the file, because it's responsible for path search.
Exactly, I'd expect zsh to handle that with an appropriately helpful
message, but past that point I quite understand that it's not the
shell's affair. Mind, even subsequent error messages might be preceded
by 'execve()' reports: ...' or something like that, it would just make
further diagnosis a bit faster. In my situation I'd be angling for
something like: "Error: binary file '/aa/bb/xxx' is not executable.
execve() reports error #54321: "file not found".
>
> It then forks, and the child process passes the full path to execve(),
> which replaces the child shell with the kernel code that is supposed
> to start up the new executable.
>
> That kernel code then fails for whatever reason -- in this case, it's
> because the 32-bit library is not found -- and returns a nonzero
> numeric exit code to the parent shell.
>
> The parent shell prints the message associated with that error code.
> It isn't responsible for guessing what caused the error; there could
> for example have been additional rounds of finding and exec'ing other
> paths of which the parent has no knowledge, before a final exit.
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: trapped in bash
[not found] ` <ab7aeb33-d091-6602-8baa-cce92300d289__26556.3400615521$1482166729$gmane$org@eastlink.ca>
@ 2016-12-19 17:47 ` Daniel Shahaf
0 siblings, 0 replies; 17+ messages in thread
From: Daniel Shahaf @ 2016-12-19 17:47 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
Ray Andrews wrote on Mon, Dec 19, 2016 at 08:26:43 -0800:
> On 18/12/16 09:48 PM, Bart Schaefer wrote:
> >The shell finds the file, because it's responsible for path search.
> Exactly, I'd expect zsh to handle that with an appropriately helpful
> message, but past that point I quite understand that it's not the shell's
> affair. Mind, even subsequent error messages might be preceded by
> 'execve()' reports: ...' or something like that, it would just make further
> diagnosis a bit faster.
Yes, error messages should generally be signed.
Perhaps something along these lines? —
diff --git a/Src/exec.c b/Src/exec.c
index 7e29e9c..37d4690 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -699,7 +699,7 @@ execute(LinkList args, int flags, int defpath)
if (arg0 == s || unset(PATHDIRS) ||
(arg0[0] == '.' && (arg0 + 1 == s ||
(arg0[1] == '.' && arg0 + 2 == s)))) {
- zerr("%e: %s", lerrno, arg0);
+ zerr("execve: %e: %s", lerrno, arg0);
_exit((lerrno == EACCES || lerrno == ENOEXEC) ? 126 : 127);
}
break;
@@ -774,7 +774,7 @@ execute(LinkList args, int flags, int defpath)
}
if (eno)
- zerr("%e: %s", eno, arg0);
+ zerr("execve: %e: %s", eno, arg0);
else if (commandnotfound(arg0, args) == 0)
_exit(lastval);
else
diff --git a/Test/C05debug.ztst b/Test/C05debug.ztst
index 9a8df1d..ee2c1b8 100644
--- a/Test/C05debug.ztst
+++ b/Test/C05debug.ztst
@@ -52,15 +52,9 @@
# Failure
exit 10
HERE
- $ZTST_testdir/../Src/zsh -f ./zsh-trapreturn-bug2 2>erroutput.dif
- mystat=$?
- (
- setopt extendedglob
- print ${"$(< erroutput.dif)"%%:[^:]#: ./fdasfsdafd}
- )
- (( mystat == 0 ))
+ $ZTST_testdir/../Src/zsh -f ./zsh-trapreturn-bug2
0: trapreturn handling bug is properly fixed
->./zsh-trapreturn-bug2:5
+*?./zsh-trapreturn-bug2:5: execve:*./fdasfsdafd
fn() {
setopt localtraps localoptions debugbeforecmd
diff --git a/Test/E01options.ztst b/Test/E01options.ztst
index 45df9f5..d40dc2e 100644
--- a/Test/E01options.ztst
+++ b/Test/E01options.ztst
@@ -782,7 +782,7 @@
>File in upper dir
>File in lower dir
>unsetting option...
-?(eval):14: no such file or directory: pathtestdir/findme
+?(eval):14: execve: no such file or directory: pathtestdir/findme
(setopt pathdirs; path+=( /usr/bin ); type ./env)
1:whence honours PATH_DIRS option
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-12-19 17:50 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-16 15:33 trapped in bash Ray Andrews
2016-12-16 21:51 ` Aaron Schrab
2016-12-16 22:39 ` Ray Andrews
2016-12-16 23:05 ` Bart Schaefer
2016-12-17 20:27 ` Ray Andrews
2016-12-17 20:43 ` Bart Schaefer
2016-12-17 22:40 ` Ray Andrews
[not found] ` <5855BEF2.6090208__18199.534857604$1482015164$gmane$org@eastlink.ca>
2016-12-18 15:06 ` Daniel Shahaf
2016-12-18 15:54 ` Ray Andrews
2016-12-19 0:32 ` Daniel Shahaf
2016-12-19 2:30 ` Bart Schaefer
2016-12-19 4:29 ` Ray Andrews
2016-12-19 5:48 ` Bart Schaefer
2016-12-19 16:26 ` Ray Andrews
[not found] ` <ab7aeb33-d091-6602-8baa-cce92300d289__26556.3400615521$1482166729$gmane$org@eastlink.ca>
2016-12-19 17:47 ` Daniel Shahaf
2016-12-17 23:16 ` Jim
2016-12-17 23:38 ` Ray Andrews
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).