On Sat, 2016-01-30 at 19:03 -0800, Pádraig Brady wrote: > ls output really isn't amenable to further processing. > That's what find(1) is focused on. Sure... as I've said... it's neither the best example, nor the best way to solve the problem from that example.
But you can also consider things like: "get a list of files in a directory, assuming no strange filenames (i.e. such with ' or newlines are used). Simple solution: ls -1 Wanna further process these files? ls -1 | sed "s/^/'/; s/$/'/" Process them further listOfFiles="$(ls -1 | sed "s/^/'/; s/$/'/" | xargs)" or something like that Still perhaps not the best way to handle things (fails at least with newlines and ' in file names), but probably more likely to be found in the wild. It's some time ago since I last tried that, but IIRC, there were several cases of invoking bash and some more corner cases when this is done via ssh. The most obvious one would be something like: ssh -t host "ls" but this is not even what that what I vaguely remember. So one would probably need to check, whether the assumption, that the check for whether a terminal is connected or not is actually enough for all cases. Perhaps not. > Let's try and force your example into something concrete. > You're saying that people might assume files are always quoted, that's another case where it may cause trouble... > but I'm explicitly adding the --quoting option below to > see if users did notice to do that, whether further > processing of ls is valid anyway. mhh... question is just whether people actually notice that option and use it. > So yes you have a valid point, > but it's quite a contrived situation. Well it's difficult what to do... but changing the output format of such base tools like ls per default seems to call for problems. Best wishes, Chris.
smime.p7s
Description: S/MIME cryptographic signature
