Re: Is this a bug?
On 8/25/20 8:21 PM, George R Goffe wrote: > I could try running strace during all of this. Would it help? It might indicate the order in which things are happening. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
On 8/25/20 3:47 PM, George R Goffe wrote: > Chet, > > I appreciate your help with this. > > Do "we" know that bash IS trying to generate an alarm? Yes, we are fairly sure that bash is trying to `ring' the bell. When I run bind 'set bell-style audible' and type the common prefix of a set of filenames in the current directory, then hit TAB, bash rings the bell. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
I was going to suggest this analysis, but George has gotten ahead of me, so let me collate the two: My understanding is that the details of how different programs read directories differs, and how different operating systems implement those operations differs, and how different file systems under an operating system implement them differs. But overall, reading large directories can take a long time, and often the operations involved are not interruptable. (At root, that is because this is an uncommon scenario in Unix and people don't work to optimize it.) So I was going to recommend this calibration: Go to the directory in question and execute "time ls -1 >/dev/null". That gives you the maximum amount of time it will take to read that directory, and that should be an upper bound on how long it will take bash to finish whatever completion operation it is doing. George R Goffe writes: > I found how how to make konsole do a visual alarm and then tried my > failure scenario. > > I cd'd to a "big" directory and then entered "ls -al abc", > waited a few seconds then did a ctrl-c. As usual, a freeze happened. I > waited a while and then saw the visual alarm followed by the ctr-c. OK, so it looks like there is some long, uniterruptable operation happening as part of filename completion. How does the length of that freeze compare to "ls -1", as described above? > Somewhere between the request for filename completion and the > recognition of ctrl-c appears to be where the "bug" is located. > > I could try running strace during all of this. Would it help? My guess is that could reveal some particularly slow operating system call that is involved in implementing filename completion, but it would not indicate a way to improve it. Dale
Re: Is this a bug?
> On Aug 25, 2020, at 3:47 PM, George R Goffe wrote: > > I have gone searching for doc on how to set alarm behavior in > konsole. I found none. I have written a bug about his at the KDE > bug site. ARGH! They have been singularly unresponsive when it comes > to bug reports. We'll see. This suggests that Konsole does not support a typical visual bell, although I can't vouch for its accuracy or continued relevance (it's over three years old). https://unix.stackexchange.com/q/371019 vq
Re: Is this a bug?
On 8/24/20 4:15 PM, George R Goffe wrote: > Chet, > > I'm not seeing any visual "bells". The audio part of this computer is > broken... NO sound... I'm not sure what I can do about that. If the visual bell doesn't work and the sound is broken, you're not going to get much of an indication no matter what you do. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
On 8/22/20 5:25 PM, George R Goffe wrote: > > Chet, > > I'm really perplexed with this situation. I type in "ls -al 123456" with > only 1 tab key. NO indication of what's happening. I hit enter and get a > message that "ls: cannot access '123456': No such file or directory" I try > the same command but with 2 tab keys... hit enter and get the same msg. Readline defaults to a visual bell, using the terminal's `vb' capability. You can set the readline `bell-style' variable to `audible' to change that. If you do, make sure your terminal emulator does something reasonable with the ^G character. > I tried the same with a partial filename that DOES exist in the directory. I > can't seem to get the filename completion to ctrl-c out. gdb sees the ctrl-c > but bash stays in the attempted filename completion. Enter doesn't work. > Ctrl-c doesn't work. Ctrl-z doesn't work. I just can't reproduce this. (Though there's no reason to expect ^Z to have any effect, since we're not running a separate job here.) > > Shouldn't there be a message about no file found presented by bash? There > appears to be NO indication that filename completion has failed to find a > file. Why would a message be appropriate here? It seems to me that the visible or audible bell is the right indicator. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
George R Goffe writes: > Shouldn't there be a message about no file found presented by bash? > There appears to be NO indication that filename completion has failed > to find a file. I'm not very experienced using filename completion, but my understanding is that completion indicates "there is no file with this prefix" by ringing the bell, and I assume that specifically means emitting a \007 character. bash depends on whatever "terminal program" it is running under to give the user an indication that \007 has been emitted. In the one system to hand, the terminal program is xterm, but it gives no indication for \007. And my memory is that over the years, support for "the bell" has been poor and inconsistent. Now maybe there's a way to configure bash to indicate no-completion-choices in a different way. > I'm at a loss as to what to do at this point. What I would like to be > able to ctrl-c out of filename completion. Sorry, I've re-read your messages and I can't tell what your situation really is. Can you describe a test case where you can't ctrl-c out of filename cmopletion, including the facts about the files involved, the exact sequence of what you type, and the behavior you observer? Dale
Re: Is this a bug?
On 2020-08-19 at 20:55 +, George R Goffe wrote: > Chet, > > I tried several times to create the problem. I think I succeeded. I did > install the "debuginfo" files I could find but it looks like libnss_sss.so's > debuginfo isn't built properly? It's supplied by sssd-client. I tried > installing sssd-client-debuginfo but it is already installed. I don't > remember doing that. Sigh... Somehow libnss_sss.so is referenced by bash? > That's what gdb thinks. > > Anyway, I tried causing the problem. ls -al zzz and then ctrl-c with > seemingly no response. I'll have to try running gdb in another konsole so I > can watch what happens when I ... I'll do that now. Stand by. > > > > I'm still not certain that I'm doing it right. When I entered ls -al zzz key> bash froze. I went to the gdb konsole and typed in where but nothing > happened. Tried several times. Tried ctrl-c on the gbb console. Got gdb's > attention. Entered where. Here's the results: > > Please let me know if this helps or if you need me to do something different. > > Regards, > > George... Since you mention sssd, and it is apparently loaded by bash, are the users and groups list from a remote server (such as LDAP)? That could cause bash (or whatever program which tries to determine the name of a user/group) to freeze if its cache expired and it needs to refetch those from a remote server (e.g. it may be downloading the list of all the users in the company). Best regards
Re: Is this a bug?
On 8/19/20 4:55 PM, George R Goffe wrote: > Chet, > > I tried several times to create the problem. I think I succeeded. I did > install the "debuginfo" files I could find but it looks like libnss_sss.so's > debuginfo isn't built properly? It's supplied by sssd-client. I tried > installing sssd-client-debuginfo but it is already installed. I don't > remember doing that. Sigh... Somehow libnss_sss.so is referenced by bash? > That's what gdb thinks. Yep, it needs it to get access to user and group data for things like tilde expansion. > Anyway, I tried causing the problem. ls -al zzz and then ctrl-c with > seemingly no response. I'll have to try running gdb in another konsole so I > can watch what happens when I ... I'll do that now. Stand by. The trace you sent shows readline waiting in pselect for user input, so it must be after the directory read was interrupted. The only thing I can suggest is to defer the attach in gdb until bash appears frozen. That may not work, but it's better than what you got. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
On 8/19/20 1:14 PM, George R Goffe wrote: > Chet, > > How can I help capture data about this problem? > > When I run bash in one konsole and it hangs, I do an strace on that pid and > the strace -xvfp always shows pselect. Eventually, the results come > back but til then, the session is frozen. You can try running gdb on bash from another terminal, attaching to the hanging bash process with `attach ', and generating a backtrace from gdb. That would at least give you the call stack. Make sure to run the bash instance you're testing with `--noprofile --norc' to get as vanilla an environment as possible. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
Chet, How can I help capture data about this problem? When I run bash in one konsole and it hangs, I do an strace on that pid and the strace -xvfp always shows pselect. Eventually, the results come back but til then, the session is frozen. I suppose I could run strace to a file on bash and make (or try) the failure appear. Your thoughts? Regards, George... George... On Wednesday, August 19, 2020, 5:58:03 AM PDT, Chet Ramey wrote: On 8/19/20 12:02 AM, George R Goffe wrote: > Chet, > > I've been thinking about what you've said below... that bash is waiting for > input. If this were the case, ctrl-c would return to the bash prompt > immediately. Yes? What I'm seeing is that with a partial filename entered > followed by the tab key is hit which results in nothing due to an > uninterriputible sleep. Ctrl-c does not stop the filename completion process. > > Does this make any sense? If that were the case, and it might be, the pselect is a red herring. The filename completion process doesn't use pselect. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
Re: Is this a bug?
On 8/19/20 12:02 AM, George R Goffe wrote: > Chet, > > I've been thinking about what you've said below... that bash is waiting for > input. If this were the case, ctrl-c would return to the bash prompt > immediately. Yes? What I'm seeing is that with a partial filename entered > followed by the tab key is hit which results in nothing due to an > uninterriputible sleep. Ctrl-c does not stop the filename completion process. > > Does this make any sense? If that were the case, and it might be, the pselect is a red herring. The filename completion process doesn't use pselect. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
On Tue, Aug 18, 2020 at 7:57 PM George R Goffe wrote: > > Chet, > > Thanks for your response. > > I'm running konsoles (KDE). I have tried complettion but don't see any > evidence of bell ringing. Not even a flash. > > Do you think that bash have a problem with konsole? Maybe it's a konsole bug? > > > I'll look at konsole docs for anything that speaks of "alarm bells", visual > or otherwise and report back here. Ok? You can use pstack to see the call stack. regards, Dmitry
Re: Is this a bug?
On 8/18/20 5:14 PM, George R Goffe wrote: > Chet, > > > Please accept my apology for not responding to your email sooner. > > I have the bash source from the(?) repository. I followed Dimitris suggestion > and found bash hung in a system call named "pselect". I did a grep on the > source and found the only two ".c" files using "pselect": If it's in pselect, it's waiting for input. It's probably not performing completion at all. It may have read the directory, found no common prefix for the files it found, `rang' the visible bell, and gone back to waiting to read the next input character. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
Are you trying to run autocompletion on an nfs mount? Are you using ''ls'' to autocomplete and if so did you run \ls /path/to/dir .. ? Maybe worth to mention the bash version you are using. Op do 6 aug. 2020 19:53 schreef George R Goffe : > Hi, > > I apologize for bothering you with this question. > > I have several directories on a system with > 300k files. When I use > filename completion bash freezes for over a minute depending on the number > of files. I'm pretty sure that bash has to read the directory to do the > completion but the read appears to be uninterruptible. Is this a bug? > > Again, I apologize for bothering you with this. > > Best regards, > > George... > >
Re: Is this a bug?
On 8/6/20 1:53 PM, George R Goffe wrote: > Hi, > > I apologize for bothering you with this question. > > I have several directories on a system with > 300k files. When I use filename > completion bash freezes for over a minute depending on the number of files. > I'm pretty sure that bash has to read the directory to do the completion but > the read appears to be uninterruptible. Is this a bug? Can you tell what system call bash is executing? Some file systems make the system call underlying readdir() uninterruptible. In general, the readline filename completion function that calls readdir only reads a single directory entry at a time, and returns it to a caller. If the SIGINT causes readdir to return NULL, the function returns normally. If readdir returns a valid entry, the caller (e.g., rl_completion_matches) checks for receipt of a signal. That should be enough to terminate the directory read. > Again, I apologize for bothering you with this. No bother. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Is this a bug?
On Thu, Aug 6, 2020 at 1:54 PM George R Goffe wrote: > I have several directories on a system with > 300k files. When I use filename > completion bash freezes for over a minute depending on the number of files. > I'm pretty sure that bash has to read the directory to do the completion but > the read appears to be uninterruptible. Is this a bug? Why don't you run strace (or truss or whatever you have on your system) and see which syscall bash is blocked in? regards, Dmitry
Re: Is this a bug by any chance?
On Mon, Oct 07, 2019 at 04:23:44PM +0200, Andreas Schwab wrote:
> On Okt 07 2019, Greg Wooledge wrote:
>
> > x=(1 2 3 4 5 -n '/*' 'hello world')
> > for z in "${x[@]}"; do
> > printf %s "$z"
> > done
> > echo
>
> (IFS=; printf '%s\n' "${x[*]}")
Or avoid the fork():
printf %s "${x[@]}"
echo
I preserved the original poster's loop, because it's probably
another !b9 question.
Re: Is this a bug by any chance?
On Okt 07 2019, Greg Wooledge wrote:
> x=(1 2 3 4 5 -n '/*' 'hello world')
> for z in "${x[@]}"; do
> printf %s "$z"
> done
> echo
(IFS=; printf '%s\n' "${x[*]}")
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Is this a bug by any chance?
On Mon, Oct 07, 2019 at 08:05:12PM +0700, pepa65 wrote:
> > On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports
> > for the GNU Bourne Again SHell wrote:
> >> I was expecting to see:
> >> 12345
> >
> > If you want to create a *list* and iterate over that list, one element
> > at a time, use arrays instead of string variables.
> >
> > x=(1 2 3 4 5)
> > for z in "${x[@]}"; do
> > echo "$z"
> > done
>
> Just to be clear (as nobody has mentioned this) to get them all on the
> same line, you need "echo -n", and you can do this without using arrays:
>
> x="1 2 3 4 5"
> for z in $x
> do echo -n "$z"
> done
This has some issues. echo -n will fail if one of the list elements is
an option recognized by echo. The unquoted $x expansion will fail if
one of the list elements is a glob that matches some files, or a glob
that matches no files if nullglob is active.
Also, the list-in-a-string gives you absolutely no way to handle list
elements that contain internal whitespace. This is what arrays are for.
Please use the arrays.
x=(1 2 3 4 5 -n '/*' 'hello world')
for z in "${x[@]}"; do
printf %s "$z"
done
echo
Re: Is this a bug by any chance?
> On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports for
> the GNU Bourne Again SHell wrote:
>> I was expecting to see:
>> 12345
>
> If you want to create a *list* and iterate over that list, one element
> at a time, use arrays instead of string variables.
>
> x=(1 2 3 4 5)
> for z in "${x[@]}"; do
> echo "$z"
> done
Just to be clear (as nobody has mentioned this) to get them all on the
same line, you need "echo -n", and you can do this without using arrays:
x="1 2 3 4 5"
for z in $x
do echo -n "$z"
done
Cheers,
Peter
Re: Is this a bug by any chance?
On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports for
the GNU Bourne Again SHell wrote:
> I was expecting to see:
> 12345
> #!./bash -xv
> x="1 2 3 4 5"
> for z in "$x"
> do
> echo "$z"
> done
> exit 0
Not a bug. You've created a string of length 9 characters, and
you've told bash to iterate once, using this string as the contents of
variable z.
If you want to create a *list* and iterate over that list, one element
at a time, use arrays instead of string variables.
x=(1 2 3 4 5)
for z in "${x[@]}"; do
echo "$z"
done
See and
.
Re: Is this a bug by any chance?
On Sat, 5 Oct 2019 18:48:35 + (UTC) George R Goffe via Bug reports for the GNU Bourne Again SHell wrote: > Hi, > > I just built the latest bash in an effort to determine if thie script shows a > bug or a ufu. Can you help me please? > > I was expecting to see: > 12345 > > Best regards AND thanks for your help, > > George... > > #!./bash -xv > x="1 2 3 4 5" > + x='1 2 3 4 5' > for z in "$x" > do > echo "$z" > done > + for z in "$x" > + echo '1 2 3 4 5' > 1 2 3 4 5 > exit 0 > + exit 0 > > It's definitely not a bug. Quoting the expansion inhibits word splitting. Your loop iterates once over a single word. Said word is conveyed to echo as a single argument. In this case, said argument is printed by echo, with the addition of a newline character. If your ultimate intent is to store an arbitrary list of strings in a variable prior to iterating over them, you should use an array variable instead. As such, this would be a topic better suited to the help-bash list. -- Kerin Millar
Is this a bug by any chance?
Hi, I just built the latest bash in an effort to determine if thie script shows a bug or a ufu. Can you help me please? I was expecting to see: 12345 Best regards AND thanks for your help, George... #!./bash -xv x="1 2 3 4 5" + x='1 2 3 4 5' for z in "$x" do echo "$z" done + for z in "$x" + echo '1 2 3 4 5' 1 2 3 4 5 exit 0 + exit 0
Re: Question: is this a bug in BASh (pre-exec trap)
On 9/9/16 2:00 PM, Matthew Giassa wrote:
> Good day,
>
> I've been doing some testing with the bash-prexec script which uses a
> DEBUG trap to issue user-supplied functions before executing each
> command (https://github.com/rcaloras/bash-preexec).
>
> Here is a minimal working example
> (https://github.com/rcaloras/bash-preexec/issues/25) which causes
> background subshells to kill the current session:
>
> # Causes login shells to logout
> # Look like bash versions > 4.2.46
> set -o functrace > /dev/null 2>&1
> no_op() { :;}
> trap 'no_op' DEBUG;
> # Any command in a subshell and background
> ( pwd ) &
>
> Is this a bug or issue in BASh itself, or is it simply a limitation of
> using pre-exec functionality?
I will look at this after bash-4.4 is released. If it's a bug with bash,
it's probably bash setting the terminal process group incorrectly when
running the DEBUG trap.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Question: is this a bug in BASh (pre-exec trap)
Good day,
I've been doing some testing with the bash-prexec script which uses a
DEBUG trap to issue user-supplied functions before executing each
command (https://github.com/rcaloras/bash-preexec).
Here is a minimal working example
(https://github.com/rcaloras/bash-preexec/issues/25) which causes
background subshells to kill the current session:
# Causes login shells to logout
# Look like bash versions > 4.2.46
set -o functrace > /dev/null 2>&1
no_op() { :;}
trap 'no_op' DEBUG;
# Any command in a subshell and background
( pwd ) &
Is this a bug or issue in BASh itself, or is it simply a limitation of
using pre-exec functionality?
Thank you.
Re: Is this a bug in [[ -f ]]?
Hello Eric, On Fri, Aug 19, 2011 at 5:04 PM, Eric Blake wrote: > On 08/19/2011 08:45 AM, Suvayu Ali wrote: >> >> I am trying to test if a file exists and then source it. My problem is >> the test succeeds even if the variable is empty! If I pass no argument >> at all, it still succeeds. To give you an example: >> >> $ unset bla >> $ [ -f $bla ]&& echo yes >> yes >> $ [ -f ]&& echo yes >> yes > > Both expected behaviors, and evidence of your lack of quoting. > > Remember, the behavior of [] depends on how many arguments are present. > > [ -f "$bla" ] (note the "") - guarantees that there are exactly two > arguments, so it proceeds with the two-argument test where -f is the > operator and "$bla" is the file name. > > [ -f ] (which is the same as [ -f $bla ] if $bla is empty, note the lack of > "") - there is exactly one argument, so it proceeds with the one-argument > test of whether the argument (the literal string -f) is empty (it is not). > > Furthermore, [ -f $bla ] is different than [[ -f $bla ]]. [ is a POSIX > utility, and mandated to do all argument word expansion before [ ever gets a > chance to see what arguments it was given - if $bla is empty or has spaces, > you changed the number of arguments that are given to [. [[ is a bash (and > ksh) extension that is part of the shell syntax (similar to how () for > subshells is part of the syntax), thus it knows how many words, > _pre-expansion_, were present, and the fact that $bla was unquoted is not a > problem, [[ -f $bla ]] is a safe way to check if $bla is a file even if $bla > is empty or contains spaces. > Thanks a lot for the very clear explanation. I'll be careful in the future. :) -- Suvayu Open source is the future. It sets us free.
Re: Is this a bug in [[ -f ]]?
On 08/19/2011 08:45 AM, Suvayu Ali wrote: I am trying to test if a file exists and then source it. My problem is the test succeeds even if the variable is empty! If I pass no argument at all, it still succeeds. To give you an example: $ unset bla $ [ -f $bla ]&& echo yes yes $ [ -f ]&& echo yes yes Both expected behaviors, and evidence of your lack of quoting. Remember, the behavior of [] depends on how many arguments are present. [ -f "$bla" ] (note the "") - guarantees that there are exactly two arguments, so it proceeds with the two-argument test where -f is the operator and "$bla" is the file name. [ -f ] (which is the same as [ -f $bla ] if $bla is empty, note the lack of "") - there is exactly one argument, so it proceeds with the one-argument test of whether the argument (the literal string -f) is empty (it is not). Furthermore, [ -f $bla ] is different than [[ -f $bla ]]. [ is a POSIX utility, and mandated to do all argument word expansion before [ ever gets a chance to see what arguments it was given - if $bla is empty or has spaces, you changed the number of arguments that are given to [. [[ is a bash (and ksh) extension that is part of the shell syntax (similar to how () for subshells is part of the syntax), thus it knows how many words, _pre-expansion_, were present, and the fact that $bla was unquoted is not a problem, [[ -f $bla ]] is a safe way to check if $bla is a file even if $bla is empty or contains spaces. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: Is this a bug in [[ -f ]]?
Hi everyone, Greg Wooledge eeg.ccf.org> writes: > > On Thu, Aug 18, 2011 at 12:35:37PM -0400, Steven W. Orr wrote: > > lrwxrwxrwx. 1 sorr fc5 Aug 18 08:48 err -> errio > > -rw-rw-r--. 1 sorr fc 3816 Aug 18 08:48 errio > > > *836 > [[ -f err ]] > > 837 > echo $? # BAD answer > > 0 > > Sounds like you want this: > > http://mywiki.wooledge.org/BashFAQ/097 - How do I determine whether a > symlink is dangling (broken)? > > I follow the reasoning above, but I still have a related but not exactly the same issue. I am trying to test if a file exists and then source it. My problem is the test succeeds even if the variable is empty! If I pass no argument at all, it still succeeds. To give you an example: $ unset bla $ [ -f $bla ] && echo yes yes $ [ -f ] && echo yes yes I don't understand this behaviour. I would have expected this to fail since $bla is blank. Can someone please explain? Thanks a lot. PS: I am not subscribed to the list, could you please cc me to any responses. -- Suvayu Open source is the future. It sets us free.
Re: Is this a bug in [[ -f ]]?
On Thu, Aug 18, 2011 at 12:35:37PM -0400, Steven W. Orr wrote: > lrwxrwxrwx. 1 sorr fc5 Aug 18 08:48 err -> errio > -rw-rw-r--. 1 sorr fc 3816 Aug 18 08:48 errio > *836 > [[ -f err ]] > 837 > echo $? # BAD answer > 0 Sounds like you want this: http://mywiki.wooledge.org/BashFAQ/097 - How do I determine whether a symlink is dangling (broken)?
Re: Is this a bug in [[ -f ]]?
On 08/18/2011 10:35 AM, Steven W. Orr wrote: I have a symlink file and if if I test it I get success status with -f. 831 > ls -l errio err lrwxrwxrwx. 1 sorr fc 5 Aug 18 08:48 err -> errio -rw-rw-r--. 1 sorr fc 3816 Aug 18 08:48 errio 832 > [[ -f errio ]] 833 > echo $? # Good answer 0 *834 > [[ -h errio ]] 835 > echo $? # Good answer 1 *836 > [[ -f err ]] 837 > echo $? # BAD answer 0 Good answer. The man page says that symlinks are dereferenced for most tests (-h and -L being the exceptions). Since err is a symlink that resolves, -f err is true. Is this a bug? Is there a workaround? Am I doing something wrong? Merely that you were expecting -f to mean 'file and not symlink' rather than what was documented of 'file or symlink to file'. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Is this a bug in [[ -f ]]?
I have a symlink file and if if I test it I get success status with -f. 831 > ls -l errio err lrwxrwxrwx. 1 sorr fc5 Aug 18 08:48 err -> errio -rw-rw-r--. 1 sorr fc 3816 Aug 18 08:48 errio 832 > [[ -f errio ]] 833 > echo $?# Good answer 0 *834 > [[ -h errio ]] 835 > echo $?# Good answer 1 *836 > [[ -f err ]] 837 > echo $?# BAD answer 0 *838 > [[ -h err ]] # Good answer 839 > echo $? 0 The man page says that -f should succeed if it exists and it's a regular file. GNU bash, version 4.0.35(1)-release (x86_64-redhat-linux-gnu) Is this a bug? Is there a workaround? Am I doing something wrong? TIA -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net
Re: is this a bug?
> > It's not a bug. the exit status of a command, the "return" of your > > function, is limited to the numbers 0-255. > > It's 0-128, actually. Whoops, no, you're right. You just can't count on exit statuses greater than 127 not conflicting with processes exiting due to a signal, so practice is to limit exit statuses to 0-127. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: is this a bug?
> It's not a bug. the exit status of a command, the "return" of your > function, is limited to the numbers 0-255. It's 0-128, actually. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: is this a bug?
On Nov 14, 2007 7:26 AM, naruto canada <[EMAIL PROTECTED]> wrote:
> function fact {
> local n=$1
> if [ "$n" -eq 0 ]; then
> return 1
> else
> fact $(( $n - 1 ))
> return $(( $n * $? ))
> fi
> }
>
> for i in `seq 0 11`; do
> fact $i ; echo $?
> done
>
>
> 1
> 1
> 2
> 6
> 24
> 120
> 208
> 176
> 128
> 128
> 0
> 0
>
> the results are wrong for 6 and above.
> is this a bug?
>
It's not a bug. the exit status of a command, the "return" of your
function, is limited to the numbers 0-255.
You need to either use the output of your function or a global
variable if you want more than that.
is this a bug?
function fact {
local n=$1
if [ "$n" -eq 0 ]; then
return 1
else
fact $(( $n - 1 ))
return $(( $n * $? ))
fi
}
for i in `seq 0 11`; do
fact $i ; echo $?
done
1
1
2
6
24
120
208
176
128
128
0
0
the results are wrong for 6 and above.
is this a bug?
