Exit status 0 when the file is moved out from under a script
I'm running: GNU bash, version 2.05b.0(1)-release (i686-pc-linux-gnu) Copyright (C) 2002 Free Software Foundation, Inc. Kernel 2.4.22 on i686 When running a bash script from NFS, and a stale NFS file handle is generated (in my case from saving over the script while it's running, which is indeed a bad habit), the script dies with exit status zero. This should exit with a non-zero status, since it is an error condition. Here's the last bit of an strace from a script doing just that: rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 read(255, 0x80ef008, 8176) = -1 ESTALE (Stale NFS file handle) exit_group(0) = ? -Rob -- _ Rob Ewaschuk http://rob.infinitepigeons.org/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash - confusing the user - a headsup/FYI/whatever
New year greetings from Sweden! Below you find an issue that I have no intention/wish to discuss further, I just wish to bring it forth to make it get a "known issue" status. Reply-to set to bug-bash Expected result: $ echo "a b c d e f g" | \ ( while read first second ;do echo "got $first" ;done ) got a The above works when IFS is set as in $ echo -n "$IFS" | od -t x1z 000 20 09 0a > ..< 003 Problem: If I understand the "$ help read" text correctly the following variation should work, but it doesn't and additionally displays a "totally off" error message. $ echo "a b c d e f g" | \ ( IFS=" " while read first remainder ;do echo "got $first" ;done ) bash: syntax error near unexpected token `do' $ bash --version GNU bash, version 3.00.16(1)-release (i686-pc-linux-gnu) Copyright (C) 2004 Free Software Foundation, Inc. Tested on a two month old Gentoo and on a fresh cygwin (www.cygwin.com) with the same bash version. /H -- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash - confusing the user - a headsup/FYI/whatever
Hannu E K Nevalainen wrote: > Problem: > If I understand the "$ help read" text correctly the following variation > should work, but it doesn't and additionally displays a "totally off" error > message. > > $ echo "a b c d e f g" | \ > ( IFS=" " while read first remainder ;do echo "got $first" ;done ) > bash: syntax error near unexpected token `do' Assignment statements may only precede simple commands, not compound commands like `while'. The assignment prevents `while' from being recognized as a reserved word. To do what you want, move the assignment to IFS between the `while' and `read'. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Can't get the set-user-id bit to work
I see that you have resolved your problem with bad permissions on /tmp. But I wanted to follow another line of discussion. Sebastian Tennant wrote: > [...test cases of suid-scripts...] > A cron.daily script handles mandb. I elected to install it with the > set-user-id bit set, as you can see: > > /usr/lib/man-db: > used 220 available 573264 > drwxr-xr-x2 root root 4096 Oct 16 15:13 . > drwxr-xr-x 116 root root 24576 Dec 14 11:49 .. > -rwsr-xr-x1 man root 86932 Sep 21 13:23 man > -rwsr-xr-x1 man root 96808 Sep 21 13:23 mandb Actually if you look at mandb it is not a script but a binary. I think this may be obvious to you now but reading the above I wanted to clarify it for the mail archive and the readers that follow. Setting suid on binaries is okay. Setting suid on scripts is not. On my system: file /usr/lib/man-db/mandb /usr/lib/man-db/mandb: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), stripped It is okay to suid a binary and the Debian configuration is designed to work with that setting. If it were a script then that would be a bug to be reported and fixed. > Every day I receive the same message in my inbox: > > /etc/cron.daily/man-db script: > mandb: can't create a temporary filename: Permission denied That has become a well known symptom for me in my lab that someone created a separate disk partition to be used for /tmp as root with a umask of 02 or 022 and then forgot to change the permission when they released the machine to production. Most system processes run as root and can still create temporary files in /tmp. Unless a user reports that they cannot create files in /tmp the first indication is the mail from the cron run of the mandb program. Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
