[arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
Guys, I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit: 15:10 nirvana:~/dt/compiz/compizX11> l total 24 drwxr-xr-x 6 david david 4096 May 18 15:04 . drwxr-xr-x 9 david dcr 4096 May 18 15:04 .. drwxr-xr-x 2 david david 4096 May 18 15:03 i586 drwxr-xr-x 2 david david 4096 May 18 15:03 noarch drwxr-xr-x 2 david david 4096 May 18 15:03 src drwxr-xr-x 2 david david 4096 May 18 15:03 x86_64 15:11 nirvana:~/dt/compiz/compizX11> for i in $(ls); do ls ${i}; done ls: cannot access i586: No such file or directory ls: cannot access noarch: No such file or directory ls: cannot access src: No such file or directory ls: cannot access x86_64: No such file or directory 15:11 nirvana:~/dt/compiz/compizX11> for i in $(ls -d ./*); do ls ${i}; done ls: cannot access ./i586: No such file or directory ls: cannot access ./noarch: No such file or directory ls: cannot access ./src: No such file or directory ls: cannot access ./x86_64: No such file or directory Huh? Same thing on a suse box: 15:14 alchemy:~/dt/compiz/compiz_11.0> l total 24 drwxr-xr-x 6 david dcr 4096 2010-05-17 23:56 ./ drwxr-xr-x 9 david dcr 4096 2010-05-18 10:28 ../ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:24 i586/ drwxr-xr-x 2 david dcr 4096 2010-05-17 23:56 noarch/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:22 src/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:21 x86_64/ 15:15 alchemy:~/dt/compiz/compiz_11.0> for i in $(ls); do ls -1 ${i}; done compiz-0.8.6-46.1.i586.rpm compiz-bcop-0.8.4-6.1.i586.rpm compizconfig-settings-manager-0.8.4-4.4.i586.rpm compiz-plugins-extra-0.8.6-8.3.i586.rpm compiz-plugins-extra-devel-0.8.6-8.3.i586.rpm <snip> What could keep the simple cli from working on Arch? I know this stuff worked before updates this morning... What should I look at? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Tue, May 18, 2010 at 16:17, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
In short, you're doing it wrong. http://mywiki.wooledge.org/ParsingLs
On 05/18/2010 03:23 PM, Daenyth Blank wrote:
On Tue, May 18, 2010 at 16:17, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
In short, you're doing it wrong.
Thanks Daenyth, Yes, I agree with the article, but the concerns are limited to Internal File Separator ($IFS) issues. If you properly handle $IFS issues, like: OLDIFS=$IFS # (default is <space><tab><newline>: IFS=$' \t\n') IFS=$'\n' for i in $(ls); do echo "whatever $i"; done IFS=$OLDIFS # not really required if run in a script because your present # environment will be protected by execution in a subshell. If used # as a one-liner, just enclose your cli in parenthesis for the # same protection. i.e. '( your code )' forces your code to execute # in a subshell. In my instance: 01:13 alchemy:~/dt/compiz/compiz_11.0> l total 24 drwxr-xr-x 6 david dcr 4096 2010-05-17 23:56 ./ drwxr-xr-x 9 david dcr 4096 2010-05-18 10:28 ../ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:24 i586/ drwxr-xr-x 2 david dcr 4096 2010-05-17 23:56 noarch/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:22 src/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:21 x86_64/ I would still expect my original command line to work. Aaron and Sergey nailed down where I messed up by putting my alias in /etc/bash.bashrc.local. Though I still don't understand why having it in /etc/bash.bashrc.local instead of ~/.bashrc makes a difference. That's what I need to learn. I'll poke around and report back if somebody doesn't answer it first. That's something I want to understand. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Tue, 18 May 2010 22:17:48 +0200, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
15:10 nirvana:~/dt/compiz/compizX11> l total 24 drwxr-xr-x 6 david david 4096 May 18 15:04 . drwxr-xr-x 9 david dcr 4096 May 18 15:04 .. drwxr-xr-x 2 david david 4096 May 18 15:03 i586 drwxr-xr-x 2 david david 4096 May 18 15:03 noarch drwxr-xr-x 2 david david 4096 May 18 15:03 src drwxr-xr-x 2 david david 4096 May 18 15:03 x86_64
15:14 alchemy:~/dt/compiz/compiz_11.0> l total 24 drwxr-xr-x 6 david dcr 4096 2010-05-17 23:56 ./ drwxr-xr-x 9 david dcr 4096 2010-05-18 10:28 ../ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:24 i586/ drwxr-xr-x 2 david dcr 4096 2010-05-17 23:56 noarch/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:22 src/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:21 x86_64/
You probably did check the aliases. (and I see a difference in the first and second '> l' with the trailing slash. -- Jeroen Op 't Eynde - jeroen@xprsyrslf.be - http://xprsyrslf.be To read: http://en.wikipedia.org/wiki/Posting_style#Bottom-posting
David C. Rankin wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
What could keep the simple cli from working on Arch? I know this stuff worked before updates this morning... What should I look at?
Bash was updated from 4.1.5(2) to 4.1.7(2). I can't reproduce it, though. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
David C. Rankin wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
What could keep the simple cli from working on Arch? I know this stuff worked before updates this morning... What should I look at? Bash was updated from 4.1.5(2) to 4.1.7(2). I can't reproduce it, though.
I cannot reproduce it either and suspect that your "ls" under $() is not the real ls, but an alias. I've played with some, and they indeed produce bad output. Cheers, Sergey
On Tue, May 18, 2010 at 3:47 PM, Sergey Manucharian <ingeniware@gmail.com> wrote:
Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
David C. Rankin wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
What could keep the simple cli from working on Arch? I know this stuff worked before updates this morning... What should I look at? Bash was updated from 4.1.5(2) to 4.1.7(2). I can't reproduce it, though.
I cannot reproduce it either and suspect that your "ls" under $() is not the real ls, but an alias. I've played with some, and they indeed produce bad output.
If this is the case, replace "ls" with "/bin/ls" in the above and try again
you may want to try for i in $(`which ls` -d .) ; do `which ls` $(`which pwd`)/$i; done it does work here Samuel Martín Moro {EPITECH.} tek4 CamTrace S.A.S "Nobody wants to say how this works. Maybe nobody knows ..." Xorg.conf(5) On Tue, May 18, 2010 at 10:58 PM, Aaron Griffin <aaronmgriffin@gmail.com>wrote:
On Tue, May 18, 2010 at 3:47 PM, Sergey Manucharian <ingeniware@gmail.com> wrote:
Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
David C. Rankin wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
What could keep the simple cli from working on Arch? I know this stuff worked before updates this morning... What should I look at? Bash was updated from 4.1.5(2) to 4.1.7(2). I can't reproduce it, though.
I cannot reproduce it either and suspect that your "ls" under $() is not the real ls, but an alias. I've played with some, and they indeed produce bad output.
If this is the case, replace "ls" with "/bin/ls" in the above and try again
Using ls for something like this is never a good idea, as Daenyth's link repeatedly points out. Use bash's globbing to get the job done. for i in *; do foo $i done Also unlike ls, this won't fail because of aliases or white spaces, either. It just works(tm). d On Tue, May 18, 2010 at 5:40 PM, Samuel Martín Moro <faust64@gmail.com>wrote:
you may want to try for i in $(`which ls` -d .) ; do `which ls` $(`which pwd`)/$i; done it does work here
Samuel Martín Moro {EPITECH.} tek4 CamTrace S.A.S
"Nobody wants to say how this works. Maybe nobody knows ..." Xorg.conf(5)
On Tue, May 18, 2010 at 10:58 PM, Aaron Griffin <aaronmgriffin@gmail.com
wrote:
On Tue, May 18, 2010 at 3:47 PM, Sergey Manucharian <ingeniware@gmail.com> wrote:
Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
David C. Rankin wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
What could keep the simple cli from working on Arch? I know this stuff worked before updates this morning... What should I look at? Bash was updated from 4.1.5(2) to 4.1.7(2). I can't reproduce it, though.
I cannot reproduce it either and suspect that your "ls" under $() is not the real ls, but an alias. I've played with some, and they indeed produce bad output.
If this is the case, replace "ls" with "/bin/ls" in the above and try again
On 05/18/2010 03:58 PM, Aaron Griffin wrote:
On Tue, May 18, 2010 at 3:47 PM, Sergey Manucharian <ingeniware@gmail.com> wrote:
Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
David C. Rankin wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
What could keep the simple cli from working on Arch? I know this stuff worked before updates this morning... What should I look at? Bash was updated from 4.1.5(2) to 4.1.7(2). I can't reproduce it, though.
I cannot reproduce it either and suspect that your "ls" under $() is not the real ls, but an alias. I've played with some, and they indeed produce bad output.
If this is the case, replace "ls" with "/bin/ls" in the above and try again
01:28 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(/bin/ls); do echo -e "'ls ${i}'\n"; /bin/ls ${i}; done 'ls i586' compiz-0.8.6-46.1.i586.rpm compiz-plugins-extra-devel-0.8.6-5.2.i586.rpm <snip> Wohoo! It works.... So the bottom line is don't alias 'ls'. And, I guess, the next question would be, how or where can I safely customize the behavior of ls without screwing myself again. I had thought that setting a system wide alias for ls would be OK by setting it in /etc/bash.bashrc.local. The contents were: 01:30 nirvana:/home/backup/rpms/compiz_X11.0> cat /etc/bash.bashrc.local.sav alias ls='ls --color --group-directories-first' Just tinkering, here is what I've found. If I make the changes in ~/.bashrc, the everything works fine, but if I make the same change in /etc/bash.bashrc.local, then the problem occurs. If you want to re-create my problem, just include the following alias: alias ls='ls --color --group-directories-first' in: /etc/bash.bashrc.local Then find a simple directory and try to run: for i in $(ls); do ls ${i}; done It will bomb. Then delete the alias from /etc/bash.bashrc.local and put the 'same' alias in your ~/.bashrc. The for loop works fine ... and ... you get the customized 'ls' behavior. What I do not understand is why the difference whether you put the alias in /etc/bash.bashrc.local or ~/.bashrc? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Wed, 2010-05-19 at 01:41 -0500, David C. Rankin wrote:
So the bottom line is don't alias 'ls'. And, I guess, the next question would be, how or where can I safely customize the behavior of ls without screwing myself again.
Solution is simple: don't use ls for the for loops you're doing. I just tested it on my system, the colored files and directories give "No such file or directory", which makes sense, as the variable contains ascii chars for color information. I would suggest using globbing, why would you use for i in $(ls); while you can use for i in *;
On 05/19/2010 01:48 AM, Jan de Groot wrote:
On Wed, 2010-05-19 at 01:41 -0500, David C. Rankin wrote:
So the bottom line is don't alias 'ls'. And, I guess, the next question would be, how or where can I safely customize the behavior of ls without screwing myself again.
Solution is simple: don't use ls for the for loops you're doing. I just tested it on my system, the colored files and directories give "No such file or directory", which makes sense, as the variable contains ascii chars for color information.
I would suggest using globbing, why would you use for i in $(ls); while you can use for i in *;
Jan, Point well taken. I don't know how I fell into that trap. Globbing is the way to go. I guess it was just more logical to do for i in (the list); and when thinking about "What gives me 'the list'", the ls trap found another victim :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Tue, May 18, 2010 at 3:58 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
If this is the case, replace "ls" with "/bin/ls" in the above and try again
or if your REALLY lazy like me :) \ls the "\" runs the real ls, not the aliased version. However, Aaron's way will always work, and is usually way I use commands in my scripts. IE: the full path, as many of our machines might have more than one grep, and I might have that aliased as well.
you can also use "env ls" which I believe gets ls from the PATH -- Caleb Cushing http://xenoterracide.blogspot.com
On 05/18/2010 03:47 PM, Sergey Manucharian wrote:
Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
David C. Rankin wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work in Arch. Same cli works fine in suse. What have I messed up? To wit:
What could keep the simple cli from working on Arch? I know this stuff worked before updates this morning... What should I look at? Bash was updated from 4.1.5(2) to 4.1.7(2). I can't reproduce it, though.
I cannot reproduce it either and suspect that your "ls" under $() is not the real ls, but an alias. I've played with some, and they indeed produce bad output.
Cheers, Sergey
Ahah! I bet you are right. I have aliased ls as: alias ls='ls --color --group-directories-first' which is the way I like ls to work. Let's do a test: [01:19 nirvana:/home/david] # mv /etc/bash.bashrc.local /etc/bash.bashrc.local.sav [01:19 nirvana:/home/david] # x exit 01:19 nirvana:~> su [01:20 nirvana:/home/backup/rpms/compiz_X11.0] # for i in $(ls); do echo "dir: $i"; done dir: i586 dir: noarch dir: repodata dir: repoview dir: src dir: x86_64 now dropping back to my user shell where the alias is still applied: 01:21 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do echo "dir: $i"; done dir: i586 dir: noarch dir: repodata dir: repoview dir: src dir: x86_64 Double Huh??? Now it works?? I haven't altered the environment for this shell yet?? Let's use my original command line: 01:22 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do ls ${i}; done ls: cannot access i586: No such file or directory ls: cannot access noarch: No such file or directory ls: cannot access repodata: No such file or directory ls: cannot access repoview: No such file or directory ls: cannot access src: No such file or directory ls: cannot access x86_64: No such file or directory Ah hah! I knew I was screwing myself, I just didn't know how. Let's find out: 01:23 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do echo "'$i'"; done 'i586' 'noarch' 'repodata' 'repoview' 'src' 'x86_64' 01:24 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do echo "'ls ${i}'"; done 'ls i586' 'ls noarch' 'ls repodata' 'ls repoview' 'ls src' 'ls x86_64' 01:25 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do echo "'ls ${i}'"; ls $i; done 'ls i586' ls: cannot access i586: No such file or directory 'ls noarch' ls: cannot access noarch: No such file or directory 'ls repodata' ls: cannot access repodata: No such file or directory 'ls repoview' ls: cannot access repoview: No such file or directory 'ls src' ls: cannot access src: No such file or directory 'ls x86_64' ls: cannot access x86_64: No such file or directory ... I give up :-( ... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (11)
-
Aaron Griffin
-
Caleb Cushing
-
Crouse
-
Daenyth Blank
-
dave reisner
-
David C. Rankin
-
Jan de Groot
-
Jeroen Op 't Eynde
-
Linas
-
Samuel Martín Moro
-
Sergey Manucharian