Timeline for Why *not* parse `ls` (and what to do instead)?
Current License: CC BY-SA 4.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 17, 2021 at 17:13 | comment | added | FUZxxl |
Note that to make things worse, most implementations of ls do not quote strange file names or replace weird characters with question marks. And even GNU ls didn't do so for a long time. So even if you rely on this behaviour, your code is wrong.
|
|
| Nov 9, 2018 at 17:48 | history | edited | Anthony Geoghegan | CC BY-SA 4.0 |
fix spelling of "characters"; remove trailing irrelevant whitespace while I'm at it
|
| May 13, 2014 at 17:03 | comment | added | zwol | You know what, I think I'll upvote this answer and clarify in mine that I agree with everything it says. ;-) | |
| May 12, 2014 at 5:47 | history | edited | Lesmana | CC BY-SA 3.0 |
edited body
|
| May 12, 2014 at 5:37 | comment | added | phemmer | @mikeserv No, it all still applies even to bash. Though I'm done with this question as you're not listening to what I'm saying. | |
| May 12, 2014 at 5:06 | comment | added | mikeserv |
@Patrick - you need to note in your answer that 75% of it is generated with zsh without the compatibility variable SH_WORD_SPLIT set. It's misleading as is - and that's the whole problem in the first place. zsh.sourceforge.net/FAQ/zshfaq03.html
|
|
| May 12, 2014 at 4:37 | comment | added | mikeserv |
@Patrick - what are you talking about? What code doesn't work? And zsh is the shell with which you demonstrated more than half of your answer. So far the only argument you've come up with that I can see that is worth regarding is the multiples in the output. But I handled that with uniq. As for shell globs being faster, I'm inclined to agree. But it's not easy to get a recursive output or any of the other things ls can do - and it is not an argument in favor of Don't parse ls.
|
|
| May 12, 2014 at 4:29 | comment | added | phemmer |
@mikeserv Did you not see my comment on your question? Shell globbing is 2.5 times faster than ls. I also requested that you test your code as it does not work. What does zsh have to do with any of this?
|
|
| May 12, 2014 at 4:20 | comment | added | mikeserv |
@Patrick - and no, zsh's failing to a follow a proscribed standard such as word splitting and shell glob expansion is not my failure.
|
|
| May 12, 2014 at 4:17 | comment | added | mikeserv |
Well, @terdon I can avoid the duplicates like set $(ls -1q | uniq) and mostly I would use a shell glob - but I do not appreciate the spread of misinformation. And what if I want to do a recursive ls? Doing the same in the shell is slow. I still don't see a real reason not to parse ls - and no one has shown me differently.
|
|
| May 12, 2014 at 3:20 | comment | added | phemmer | @mikeserv sorry, didn't see your updated comment. I've added a command at the bottom of the answer that will recreate the full list of files I was using. | |
| May 12, 2014 at 3:19 | history | edited | phemmer | CC BY-SA 3.0 |
added 185 characters in body
|
| May 12, 2014 at 2:59 | history | edited | phemmer | CC BY-SA 3.0 |
added 286 characters in body
|
| May 12, 2014 at 2:32 | comment | added | terdon♦ |
@mikeserv You could avoid the duplicates with something like for f in $(ls -1q | tr " " "?" | sed 's/^/"/; s/$/"/') ; do echo "$f"; done. But why not just for f in *; do echo "$f"; done?
|
|
| May 12, 2014 at 2:32 | comment | added | phemmer | "Not the rest"? It's inconsistent behavior, and unexpected results, how is that not a reason? | |
| May 12, 2014 at 2:28 | comment | added | mikeserv | Ahh. So there are multiples and that, at least, might be a reason. Not the rest. Add a copy/paste of the command that creates these file names. 10/1 odds I can handle it easily. If not, I'll accept the answer. | |
| May 12, 2014 at 2:26 | history | edited | phemmer | CC BY-SA 3.0 |
added 1145 characters in body
|
| May 12, 2014 at 2:26 | comment | added | phemmer | @mikeserv zsh. When I switch to bash it's just as bad. I've updated for bash. | |
| May 12, 2014 at 2:21 | comment | added | mikeserv |
What is your shell? I ask because the only shell in which I get a similar result is zsh - all others such as bash, sh, and dash correctly resolve the pathnames as is POSIX specified.
|
|
| May 12, 2014 at 2:16 | comment | added | phemmer | @mikeserv updated again. See the section: In regards to just "I'm going to iterate anyway, why not use ls?" | |
| May 12, 2014 at 2:15 | history | edited | phemmer | CC BY-SA 3.0 |
added 1546 characters in body
|
| May 12, 2014 at 2:06 | comment | added | mikeserv |
Yeah - the filename is resolved after you resolve it in the shell. Of course - that's what you have to do with a glob. But if I have to do that anyway, I'd much rather have ls generate the data - sorted certain ways, recursively, and very fast - than I would otherwise. And this answer only distracts from the actual question - why not parse ls? for f in $(ls -1q)... is faster and more reliable than is for f in GLOB...
|
|
| May 12, 2014 at 2:04 | history | edited | phemmer | CC BY-SA 3.0 |
added 225 characters in body
|
| May 12, 2014 at 2:03 | comment | added | mikeserv | His solution is a glob - he suggests iterating over a glob. His exact words are: "If you just want to iterate over all the files in the current directory, use a for loop and a glob:" | |
| May 12, 2014 at 2:02 | comment | added | phemmer | @mikeserv actually his solution doesn't return a glob. I just updated my answer to clarify that point. | |
| May 12, 2014 at 2:01 | comment | added | mikeserv | Of course it might match more than one file - it's a glob! but so is his recommended solution! | |
| May 12, 2014 at 1:57 | history | answered | phemmer | CC BY-SA 3.0 |