Timeline for Why *not* parse `ls` (and what to do instead)?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 13, 2014 at 1:51 | comment | added | mikeserv | @cHao - i disagree. There is a not-so-fine line between a mantra and a wisdom. | |
| May 13, 2014 at 1:50 | comment | added | cHao | @mikeserv: The arguments against it are well-founded and well-deserved. Even you have shown them to be true. | |
| May 13, 2014 at 1:47 | comment | added | mikeserv | @cHao - i didnt argue its merits - i protested its propaganda. | |
| May 13, 2014 at 1:06 | comment | added | cHao | @mikeserv: It could be done right, if you have the time and patience. But the fact is, it is inherently error-prone. You yourself got it wrong. while arguing about its merits! That's a huge strike against it, if even the one person fighting for it fails to do it correctly. And chances are, you'll probably spend still more time getting it wrong before you get it right. I dunno about you, but most people have better to do with their time than fiddle around for ages with the same line of code. | |
| May 12, 2014 at 22:56 | comment | added | mikeserv | I upvoted this. It's good to see your own code bite you. But just because I got it wrong doesn't mean it can't be done right. I showed you a very simple way to do it this morning with ls -1qRi | grep -o '^ *[0-9]*' - that's parsing ls output, man, and it's the fastest and best way of which I know to get a list of inode numbers. | |
| May 12, 2014 at 5:34 | history | undeleted | terdon♦ | ||
| May 12, 2014 at 5:34 | history | edited | terdon♦ | CC BY-SA 3.0 | added 438 characters in body |
| May 12, 2014 at 2:38 | history | deleted | terdon♦ | via Vote | |
| May 12, 2014 at 2:37 | history | answered | terdon♦ | CC BY-SA 3.0 |