Re: echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory
Hi Greg, Thank you for your detailed explanation, I now understand the reason, and will use quote in my scripts to avoid unexpected bugs. Best Regards Lingfei Kong -- Original -- From: "Greg Wooledge";; Date: Wed, Jul 27, 2016 09:28 PM To: "Lingfei Kong"<466701...@qq.com>; Cc: "bug-bash"; Subject: Re: echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory On Wed, Jul 27, 2016 at 07:24:11PM +0800, Lingfei Kong wrote: > # touch 11 > # c='[11761][1469504252]' > # echo $c > 11 This is why you MUST ALWAYS quote your parameter expansions. echo "$c" http://mywiki.wooledge.org/Quotes http://mywiki.wooledge.org/BashGuide
Re: bug in [ -f file ] test
On 7/27/16 3:34 PM, László Házy wrote:
> You have probably not done the first command: "[user1]$ chmod g+rx
> /home/user1". In my case, there is no access problem. I can ls and cd.
> Thing is, even root gets the wrong answer if it does the "is file?" query.
I performed that command, but I tore it all down and rebuilt it anyway.
Running a system call tracer (strace) shows that stat ("/var/tmp/link", )
returns -1 with errno == EACCES. `cat' displays "Permission Denied", and
`cp' says "cannot stat".
What does strace show when you run it as user1 with a script that contains
[[ -f /var/tmp/link ]]
echo $?
?
--
``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/
Re: bug in [ -f file ] test
On Wed, Jul 27, 2016 at 03:34:19PM -0400, László Házy wrote:
> You have probably not done the first command: "[user1]$ chmod g+rx
> /home/user1". In my case, there is no access problem. I can ls and cd.
> Thing is, even root gets the wrong answer if it does the "is file?"
> query.
You're misunderstanding. We're ("they're", though I was thinking the
same thing and simply hadn't spoken up yet) saying that what you have
described is not reproducible in a regular Unix operating system. You
are encountering something unique to your special non-Unix operating
system.
The most likely theory at this point is that it's got something to do
with SELinux.
Figure out how SELinux works and how it is affecting this situation,
or simply turn it off.
It's not a bash issue. As Chet states below, it affects *every* program.
> On Wed, 2016-07-27 at 15:16 -0400, Chet Ramey wrote:
> > It's probably the case that SELinux is affecting the permissions
> > beyond
> > what the file and directory permissions indicate. I spun up a Fedora
> > 23
> > VM and created two users (user1 and user2), with the files set up as
> > you
> > describe above. When you're running as user2, no tool has access to
> > /home/user1 and /home/user1/file: I tried getfacl, ls, cd, and cat.
> >
> > You should experiment with temporarily disabling SELinux on the
> > machine,
> > or using SELinux options to disable it on /home/user1 and its
> > contents.
> >
> > Chet
> >
Re: [patch] typo in readline 7.0 beta2 release
On 7/25/16 2:56 PM, Matthias Klose wrote: > small typo building the docs. Thanks for the report and fix. > also we had release candidates before, now reverting to beta names. is this > expected? Yes, since readline and bash track the same release cycle. -- ``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/
Re: bug in [ -f file ] test
On 7/26/16 5:07 PM, László Házy wrote: > Hmm, interesting. I can reproduce your results. Thanks. > However, note the following: > > [user1]$ chmod g+rx /home/user1 > [user1]$ touch file; ls -l file > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" > [user1]$ ls -l /var/tmp/link > lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > 1 > > [user1]$ su user2 > [user2]$ [[ -f /var/tmp/link ]]; echo $? > 0 > > Something does not add up. > From experimenting, it appears that only the user who created the symlink > will get true for the file test. It's virtually certain that this is not a bug in bash, since bash just calls stat(2) on the filename supplied as an argument to -f. It's probably the case that SELinux is affecting the permissions beyond what the file and directory permissions indicate. I spun up a Fedora 23 VM and created two users (user1 and user2), with the files set up as you describe above. When you're running as user2, no tool has access to /home/user1 and /home/user1/file: I tried getfacl, ls, cd, and cat. You should experiment with temporarily disabling SELinux on the machine, or using SELinux options to disable it on /home/user1 and its contents. 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/
Re: a=$* -> crash
On 7/27/16 7:59 AM, Andreas Schwab wrote: > (gdb) r > Starting program: /bin/bash -c a=\$\* > > Program received signal SIGSEGV, Segmentation fault. > quote_string (string=string@entry=0x0) at subst.c:3940 > 3940 if (*string == 0) Thanks for the report and fix. 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/
Re: ''"$@" expansion
On 5/12/16 7:37 PM, Grisha Levit wrote: > Thanks for the pointer. Looking at that interpretation > (http://austingroupbugs.net/view.php?id=888), I noticed that it includes > one case that bash is not handling correctly: > > If there are no positional parameters, the expansion of |@| shall > generate zero fields […] however, if the expansion is embedded within a > word which contains one or more other parts that expand to a quoted > null string, these null string(s) shall still produce an empty field […] > > The provided example is: > > |set -- printf '[%s]\n' foo ''"$@" *[foo] []* | > > (Bash just prints |[foo]|). Thanks for the report. This will be fixed in bash-4.4. > The attached exp9.sub and exp.right could be used for testing all the > examples from the interpretation if desired. I removed the test cases that > included undefined behavior. Thanks, I'll take a look at adding it to the test suite. 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/
Re: bug in [ -f file ] test
> Am 27.07.2016 um 18:55 schrieb László Házy : > > Here it goes. Note that the second command you asked for returns the same as > the "file" entry in the first command. Thanks. Yeah, I meant: $ ls -Zd /home/user1 to show the entry of the directory itself, not its content. - Reuti > [user1]$ ls -Z /home/user1 > unconfined_u:object_r:user_home_t:s0 Desktop > unconfined_u:object_r:user_home_t:s0 Documents > unconfined_u:object_r:user_home_t:s0 Downloads > unconfined_u:object_r:user_home_t:s0 file > unconfined_u:object_r:audio_home_t:s0 Music > unconfined_u:object_r:user_home_t:s0 Pictures > unconfined_u:object_r:user_home_t:s0 Public > unconfined_u:object_r:user_home_t:s0 Templates > unconfined_u:object_r:user_home_t:s0 Videos > > > > > On Wed, 2016-07-27 at 18:28 +0200, Reuti wrote: >>> >>> Am 27.07.2016 um 18:13 schrieb László Házy < >>> haz...@yahoo.com >>> >: >>> >>> Yes, SELinux is active. >>> >> >> >> Fine. >> >> Can you please provide: >> >> $ ls -Z /home/user1 >> $ ls -Z /home/user1/file >> >> -- Reuti >> >> >> >>> >>> On Wed, 2016-07-27 at 17:55 +0200, Reuti wrote: >>> > > > Am 27.07.2016 um 17:36 schrieb László Házy < > > haz...@yahoo.com >> >> : >> > > > Yes, user2 has rx access to /home/user1. This is done by the first > command in the list of commands, namely: "[user1]$ chmod g+rx > /home/user1". The two users are part of the same group. > > An even more troublesome variation, involving root, is the following: > > [user1]$ touch file; ls -l file > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > The dot at the end means SELinux ACL IIRC - are you running SELinux? -- Reuti > > > [user1]$ ln -s /home/user1/file /var/tmp/link > [user1]$ ls -l /var/tmp/link > lrwxrwxrwx. 1 user1 users 17 Jul 26 15:26 /var/tmp/link -> > /home/user1/file > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > 0 > > [user1]$ su > [root]$ [[ -f /var/tmp/link ]]; echo $? > 1 > > > On Tue, 2016-07-26 at 23:26 +0200, Reuti wrote: > > >> >> >> Am 26.07.2016 um 23:07 schrieb László Házy: >> >> >> >> >>> >>> >>> >>> Hmm, interesting. I can reproduce your results. Thanks. >>> However, note the following: >>> >>> [user1]$ chmod g+rx /home/user1 >>> [user1]$ touch file; ls -l file >>> -rw-r--r--. 1 user1 users0 Jul 26 15:24 file >>> >>> [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" >>> [user1]$ ls -l /var/tmp/link >>> lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> >>> /home/user1/file >>> >>> [user1]$ [[ -f /var/tmp/link ]]; echo $? >>> 1 >>> >>> [user1]$ su user2 >>> [user2]$ [[ -f /var/tmp/link ]]; echo $? >>> 0 >>> >>> Something does not add up. >>> >>> >>> >> >> >> >> >> Does user2 have rx access to /home/user1? >> >> -- Reuti >> >> >> >> >> >>> >>> >>> >>> From experimenting, it appears that only the user who created the >>> symlink will get true for the file test. >>> >>> Thank you. >>> >>> >>> >>> >>> On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: >>> >>> >>> Are you sure "file" is a link to an actual file, not, say, a directory? $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release bash-4.3.42-3.fc23.x86_64 4.3.42(1)-release Fedora release 23 (Twenty Three) $ touch file; ln -s file link; [[ -f link ]]; echo $? 0 On Tue, Jul 26, 2016 at 12:58 PM, László Házy < haz...@yahoo.com > > > wrote: > > > > > > I am running bash 4.3.42-3 on Fedore Core 23. > > I noticed that the [ -f file ] test returns false if "file" is a > symlink. Given the intended behavior (from a long time ago), this is > wrong as the symlinks are supposed to be followed. It certainly > brakes functionality in certain existing software. > > Has the default behavior been changed somewhere along the time line > and I am not aware of it? > > > > > >>> >>> >>> >>> >>> >> >> >> >> >> >> >> > > > >>> >> >> >>
Re: bug in [ -f file ] test
Here it goes. Note that the second command you asked for returns the same as the "file" entry in the first command. Thanks. [user1]$ ls -Z /home/user1 unconfined_u:object_r:user_home_t:s0 Desktop unconfined_u:object_r:user_home_t:s0 Documents unconfined_u:object_r:user_home_t:s0 Downloads unconfined_u:object_r:user_home_t:s0 file unconfined_u:object_r:audio_home_t:s0 Music unconfined_u:object_r:user_home_t:s0 Pictures unconfined_u:object_r:user_home_t:s0 Public unconfined_u:object_r:user_home_t:s0 Templates unconfined_u:object_r:user_home_t:s0 Videos On Wed, 2016-07-27 at 18:28 +0200, Reuti wrote: > > > > Am 27.07.2016 um 18:13 schrieb László Házy : > > > > Yes, SELinux is active. > Fine. > > Can you please provide: > > $ ls -Z /home/user1 > $ ls -Z /home/user1/file > > -- Reuti > > > > > > On Wed, 2016-07-27 at 17:55 +0200, Reuti wrote: > > > > > > > > > > > > > > > Am 27.07.2016 um 17:36 schrieb László Házy < > > > > haz...@yahoo.com > > > > > > > > > > : > > > > Yes, user2 has rx access to /home/user1. This is done by the > > > > first command in the list of commands, namely: "[user1]$ chmod > > > > g+rx /home/user1". The two users are part of the same group. > > > > > > > > An even more troublesome variation, involving root, is the > > > > following: > > > > > > > > [user1]$ touch file; ls -l file > > > > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > > > > > > > > > The dot at the end means SELinux ACL IIRC - are you running > > > SELinux? > > > > > > -- Reuti > > > > > > > > > > > > > > > > > > > > > [user1]$ ln -s /home/user1/file /var/tmp/link > > > > [user1]$ ls -l /var/tmp/link > > > > lrwxrwxrwx. 1 user1 users 17 Jul 26 15:26 /var/tmp/link -> > > > > /home/user1/file > > > > > > > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > > > > 0 > > > > > > > > [user1]$ su > > > > [root]$ [[ -f /var/tmp/link ]]; echo $? > > > > 1 > > > > > > > > > > > > On Tue, 2016-07-26 at 23:26 +0200, Reuti wrote: > > > > > > > > > > > > > > > > > > > Am 26.07.2016 um 23:07 schrieb László Házy: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm, interesting. I can reproduce your results. Thanks. > > > > > > However, note the following: > > > > > > > > > > > > [user1]$ chmod g+rx /home/user1 > > > > > > [user1]$ touch file; ls -l file > > > > > > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > > > > > > > > > > > [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" > > > > > > [user1]$ ls -l /var/tmp/link > > > > > > lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> > > > > > > /home/user1/file > > > > > > > > > > > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > > > > > > 1 > > > > > > > > > > > > [user1]$ su user2 > > > > > > [user2]$ [[ -f /var/tmp/link ]]; echo $? > > > > > > 0 > > > > > > > > > > > > Something does not add up. > > > > > > > > > > > > > > > > > > > > > > > > > > > Does user2 have rx access to /home/user1? > > > > > > > > > > -- Reuti > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From experimenting, it appears that only the user who > > > > > > created the symlink will get true for the file test. > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Are you sure "file" is a link to an actual file, not, > > > > > > > say, a directory? > > > > > > > > > > > > > > $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat- > > > > > > > release > > > > > > > bash-4.3.42-3.fc23.x86_64 > > > > > > > 4.3.42(1)-release > > > > > > > Fedora release 23 (Twenty Three) > > > > > > > > > > > > > > $ touch file; ln -s file link; [[ -f link ]]; echo $? > > > > > > > 0 > > > > > > > > > > > > > > On Tue, Jul 26, 2016 at 12:58 PM, László Házy < > > > > > > > > > > > > > > haz...@yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am running bash 4.3.42-3 on Fedore Core 23. > > > > > > > > > > > > > > > > I noticed that the [ -f file ] test returns false if > > > > > > > > "file" is a symlink. Given the intended behavior (from > > > > > > > > a long time ago), this is wrong as the symlinks are > > > > > > > > supposed to be followed. It certainly brakes > > > > > > > > functionality in certain existing software. > > > > > > > > > > > > > > > > Has the default behavior been changed somewhere along > > > > > > > > the time line and I am not aware of it? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: bug in [ -f file ] test
> Am 27.07.2016 um 18:13 schrieb László Házy : > > Yes, SELinux is active. Fine. Can you please provide: $ ls -Z /home/user1 $ ls -Z /home/user1/file -- Reuti > On Wed, 2016-07-27 at 17:55 +0200, Reuti wrote: >>> >>> Am 27.07.2016 um 17:36 schrieb László Házy < >>> haz...@yahoo.com >>> >: >>> >>> Yes, user2 has rx access to /home/user1. This is done by the first command >>> in the list of commands, namely: "[user1]$ chmod g+rx /home/user1". The two >>> users are part of the same group. >>> >>> An even more troublesome variation, involving root, is the following: >>> >>> [user1]$ touch file; ls -l file >>> -rw-r--r--. 1 user1 users0 Jul 26 15:24 file >>> >> >> >> The dot at the end means SELinux ACL IIRC - are you running SELinux? >> >> -- Reuti >> >> >> >>> >>> [user1]$ ln -s /home/user1/file /var/tmp/link >>> [user1]$ ls -l /var/tmp/link >>> lrwxrwxrwx. 1 user1 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file >>> >>> [user1]$ [[ -f /var/tmp/link ]]; echo $? >>> 0 >>> >>> [user1]$ su >>> [root]$ [[ -f /var/tmp/link ]]; echo $? >>> 1 >>> >>> >>> On Tue, 2016-07-26 at 23:26 +0200, Reuti wrote: >>> Am 26.07.2016 um 23:07 schrieb László Házy: > > > Hmm, interesting. I can reproduce your results. Thanks. > However, note the following: > > [user1]$ chmod g+rx /home/user1 > [user1]$ touch file; ls -l file > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" > [user1]$ ls -l /var/tmp/link > lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> > /home/user1/file > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > 1 > > [user1]$ su user2 > [user2]$ [[ -f /var/tmp/link ]]; echo $? > 0 > > Something does not add up. > > Does user2 have rx access to /home/user1? -- Reuti > > > From experimenting, it appears that only the user who created the symlink > will get true for the file test. > > Thank you. > > > > > On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: > > >> >> >> Are you sure "file" is a link to an actual file, not, say, a directory? >> >> $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release >> bash-4.3.42-3.fc23.x86_64 >> 4.3.42(1)-release >> Fedora release 23 (Twenty Three) >> >> $ touch file; ln -s file link; [[ -f link ]]; echo $? >> 0 >> >> On Tue, Jul 26, 2016 at 12:58 PM, László Házy < >> >> haz...@yahoo.com >>> >>> wrote: >>> >> >> >> >>> >>> >>> I am running bash 4.3.42-3 on Fedore Core 23. >>> >>> I noticed that the [ -f file ] test returns false if "file" is a >>> symlink. Given the intended behavior (from a long time ago), this is >>> wrong as the symlinks are supposed to be followed. It certainly brakes >>> functionality in certain existing software. >>> >>> Has the default behavior been changed somewhere along the time line and >>> I am not aware of it? >>> >>> >>> >>> >> >> >> >> >> > > > >>> >> >> >>
Re: bug in [ -f file ] test
> Am 27.07.2016 um 17:36 schrieb László Házy : > > Yes, user2 has rx access to /home/user1. This is done by the first command in > the list of commands, namely: "[user1]$ chmod g+rx /home/user1". The two > users are part of the same group. > > An even more troublesome variation, involving root, is the following: > > [user1]$ touch file; ls -l file > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file The dot at the end means SELinux ACL IIRC - are you running SELinux? -- Reuti > [user1]$ ln -s /home/user1/file /var/tmp/link > [user1]$ ls -l /var/tmp/link > lrwxrwxrwx. 1 user1 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > 0 > > [user1]$ su > [root]$ [[ -f /var/tmp/link ]]; echo $? > 1 > > > On Tue, 2016-07-26 at 23:26 +0200, Reuti wrote: >> Am 26.07.2016 um 23:07 schrieb László Házy: >> >> >>> >>> Hmm, interesting. I can reproduce your results. Thanks. >>> However, note the following: >>> >>> [user1]$ chmod g+rx /home/user1 >>> [user1]$ touch file; ls -l file >>> -rw-r--r--. 1 user1 users0 Jul 26 15:24 file >>> >>> [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" >>> [user1]$ ls -l /var/tmp/link >>> lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file >>> >>> [user1]$ [[ -f /var/tmp/link ]]; echo $? >>> 1 >>> >>> [user1]$ su user2 >>> [user2]$ [[ -f /var/tmp/link ]]; echo $? >>> 0 >>> >>> Something does not add up. >>> >> >> >> Does user2 have rx access to /home/user1? >> >> -- Reuti >> >> >> >>> >>> From experimenting, it appears that only the user who created the symlink >>> will get true for the file test. >>> >>> Thank you. >>> >>> >>> >>> >>> On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: >>> Are you sure "file" is a link to an actual file, not, say, a directory? $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release bash-4.3.42-3.fc23.x86_64 4.3.42(1)-release Fedora release 23 (Twenty Three) $ touch file; ln -s file link; [[ -f link ]]; echo $? 0 On Tue, Jul 26, 2016 at 12:58 PM, László Házy < haz...@yahoo.com > wrote: > > I am running bash 4.3.42-3 on Fedore Core 23. > > I noticed that the [ -f file ] test returns false if "file" is a symlink. > Given the intended behavior (from a long time ago), this is wrong as the > symlinks are supposed to be followed. It certainly brakes functionality > in certain existing software. > > Has the default behavior been changed somewhere along the time line and I > am not aware of it? > > > >>> >> >> >>
Re: bug in [ -f file ] test
Yes, user2 has rx access to /home/user1. This is done by the first command in the list of commands, namely: "[user1]$ chmod g+rx /home/user1". The two users are part of the same group. An even more troublesome variation, involving root, is the following: [user1]$ touch file; ls -l file -rw-r--r--. 1 user1 users0 Jul 26 15:24 file [user1]$ ln -s /home/user1/file /var/tmp/link [user1]$ ls -l /var/tmp/link lrwxrwxrwx. 1 user1 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file [user1]$ [[ -f /var/tmp/link ]]; echo $? 0 [user1]$ su [root]$ [[ -f /var/tmp/link ]]; echo $? 1 On Tue, 2016-07-26 at 23:26 +0200, Reuti wrote: > Am 26.07.2016 um 23:07 schrieb László Házy: > > > > > Hmm, interesting. I can reproduce your results. Thanks. > > However, note the following: > > > > [user1]$ chmod g+rx /home/user1 > > [user1]$ touch file; ls -l file > > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > > > [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" > > [user1]$ ls -l /var/tmp/link > > lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> > > /home/user1/file > > > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > > 1 > > > > [user1]$ su user2 > > [user2]$ [[ -f /var/tmp/link ]]; echo $? > > 0 > > > > Something does not add up. > Does user2 have rx access to /home/user1? > > -- Reuti > > > > > > From experimenting, it appears that only the user who created the > > symlink will get true for the file test. > > > > Thank you. > > > > > > > > > > On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: > > > > > > Are you sure "file" is a link to an actual file, not, say, a > > > directory? > > > > > > $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release > > > bash-4.3.42-3.fc23.x86_64 > > > 4.3.42(1)-release > > > Fedora release 23 (Twenty Three) > > > > > > $ touch file; ln -s file link; [[ -f link ]]; echo $? > > > 0 > > > > > > On Tue, Jul 26, 2016 at 12:58 PM, László Házy > > > wrote: > > > > > > > > I am running bash 4.3.42-3 on Fedore Core 23. > > > > > > > > I noticed that the [ -f file ] test returns false if "file" is > > > > a symlink. Given the intended behavior (from a long time ago), > > > > this is wrong as the symlinks are supposed to be followed. It > > > > certainly brakes functionality in certain existing software. > > > > > > > > Has the default behavior been changed somewhere along the time > > > > line and I am not aware of it? > > > > > > > >
Re: echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory
On Wed, Jul 27, 2016 at 07:24:11PM +0800, Lingfei Kong wrote: > # touch 11 > # c='[11761][1469504252]' > # echo $c > 11 This is why you MUST ALWAYS quote your parameter expansions. echo "$c" http://mywiki.wooledge.org/Quotes http://mywiki.wooledge.org/BashGuide
Re: echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory
On Wed, Jul 27, 2016 at 2:28 PM, Lingfei Kong <466701...@qq.com> wrote: > Another reproducer: > > # c='[1][1][1]' > # touch 111 > # echo $c > 111 > # rm 111 > # echo $c > [1][1][1] > > -- Original -- > *From: * "Lingfei Kong";<466701...@qq.com>; > *Date: * Wed, Jul 27, 2016 07:24 PM > *To: * "bug-bash"; > *Subject: * echo builtin command will give the wrong value of the > variable when there is a file named: 11 in the current directory > > *Description:* > > echo builtin command will give the wrong value of the variable when there is > a file named: 11 in the current directory. > > > *Version:* > > GNU bash, version 4.2.45(1)-release-by_tst_tlinux20_v1004 > (x86_64-unknown-linux-gnu) > > GNU bash, version 4.1.2(1)-release-by_mupan_tlinux_v1004 > (x86_64-unknown-linux-gnu) > > GNU bash, version 3.2.48(1)-release-by_tst_suse_31_v1004 > (x86_64-unknown-linux-gnu) > > > *How reproducible:* > > 100% > > > *Steps to Reproduce:* > > # touch 11 > # c='[11761][1469504252]' > > *# echo $c11* > # rm 11 > # echo $c > [11761][1469504252] > > *Expected results:* > > # touch 11 > # c='[11761][1469504252]' > > *# echo $c **[11761][1469504252]* > > > > Best Regards > > Lingfei > > It's acutally a feature, juste like "echo *" will print the list of filenames matching * "echo [a-z]*" will print the list of filenames starting with a letter between a and z. [] defines a range of character like in almost every regular expression. In your case you can disable matching the filenames by quoting your expansion: echo "$c".
Re: echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory
Another reproducer: # c='[1][1][1]' # touch 111 # echo $c 111 # rm 111 # echo $c [1][1][1] -- Original -- From: "Lingfei Kong";<466701...@qq.com>; Date: Wed, Jul 27, 2016 07:24 PM To: "bug-bash"; Subject: echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory Description:echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory. Version:GNU bash, version 4.2.45(1)-release-by_tst_tlinux20_v1004 (x86_64-unknown-linux-gnu)GNU bash, version 4.1.2(1)-release-by_mupan_tlinux_v1004 (x86_64-unknown-linux-gnu)GNU bash, version 3.2.48(1)-release-by_tst_suse_31_v1004 (x86_64-unknown-linux-gnu) How reproducible:100% Steps to Reproduce:# touch 11 # c='[11761][1469504252]' # echo $c 11 # rm 11 # echo $c [11761][1469504252] Expected results:# touch 11 # c='[11761][1469504252]' # echo $c [11761][1469504252] Best RegardsLingfei
echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory
Description:echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory. Version:GNU bash, version 4.2.45(1)-release-by_tst_tlinux20_v1004 (x86_64-unknown-linux-gnu)GNU bash, version 4.1.2(1)-release-by_mupan_tlinux_v1004 (x86_64-unknown-linux-gnu)GNU bash, version 3.2.48(1)-release-by_tst_suse_31_v1004 (x86_64-unknown-linux-gnu) How reproducible:100% Steps to Reproduce:# touch 11 # c='[11761][1469504252]' # echo $c 11 # rm 11 # echo $c [11761][1469504252] Expected results:# touch 11 # c='[11761][1469504252]' # echo $c [11761][1469504252] Best RegardsLingfei
a=$* -> crash
(gdb) r
Starting program: /bin/bash -c a=\$\*
Program received signal SIGSEGV, Segmentation fault.
quote_string (string=string@entry=0x0) at subst.c:3940
3940 if (*string == 0)
diff --git a/subst.c b/subst.c
index 37d96f9..16ae3f0 100644
--- a/subst.c
+++ b/subst.c
@@ -8575,7 +8575,7 @@ param_expand (string, sindex, quoted, expanded_something,
/* If we're not quoted but we still don't want word splitting,
make
we quote the IFS characters to protect them from splitting
(e.g.,
when $@ is in the string as well). */
- else if (quoted == 0 && ifs_is_set && (pflags & PF_ASSIGNRHS))
+ else if (temp != 0 && quoted == 0 && ifs_is_set && (pflags &
PF_ASSIGNRHS))
{
temp1 = quote_string (temp);
free (temp);
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
