[ILUG] Re: script handling filenames with spaces
Ian Spillane
iantheteacher at gmail.com
Sun Aug 19 16:02:41 IST 2007
Yikes! ;-)
On 8/19/07, Brian Foster <blf at utvinternet.ie> wrote:
>
> | From: "Ian Spillane" <iantheteacher at gmail.com>
> | Date: Sun, 19 Aug 2007 11:28:43 +0100
> |
> | Piping FIND into WHILE looks elegant. Like that solution
> | myself; but for the sake of argument I did once rely on
> | this inelegant solution with temporarily replacing spaces
> | in filenames (to "{}") before looping:
> |
> | for file in $(find -name whatever | sed s/[\ ]/{}/g)
> | do
> | f=$(echo $file | sed s/{}/\ /g ) # return spaces
> | cat "$f"
> | done
> |
> | If you have to use FOR then it's a solution - but wouldn't
> | recommend. WHILE is nicely reliable for filenames.
>
> yea, I pipe stuff all the time into "while" loops
> (including, at least once, the output of another
> "while" loop!). it's a powerful trick, and if yer
> careful, only(?) fouls up on newlines-in-filenames.
>
> anyways, with respect to the above sed(1) example,
> I see three worries off the top of my head (and I'm
> ignoring the newline issue):
>
> 1st, a filename containing "{}" will go wrong.
> hence, I'd either use something find(1) should
> never output, such as "//" or "/../", albeit
> those can go wrong in a weird(?) case (left as
> an exercise to the reader). or, I'd somehow
> "escape" any contained "{}".
>
> 2nd, as written, tabs-in-filenames are not handled,
> albeit those can clearly be handled by a similar
> trick. but then you've probably got two instances
> of the 1st problem .... ;-(
>
> 3rd, echo(1) doesn't always print its arguments
> literally, even after fixing the bug in the
> above — adding the missing double-quotes:
>
> f=$(echo "$file" | sed ... )
>
> exactly what sorts of 'echo' arguments can
> foul up depends on yer system and settings,
> but examples include "-n" and "foo\123bar".
> to avoid those gotchas, and when using GNU
> bash(1)'s built-in echo(1), I often use "-E":
>
> f=$(echo -E "$file" | sed ... )
>
> albeit printf(1) is perhaps the best solution,
> but on older systems it's not a shell built-in.
>
> another possible bug in the above is if the filename
> happens to be something like "--help" then the cat(1)
> may foul up? (actually, the shown find(1) tends to
> prefix all names with "./" so this isn't a problem.)
>
> of course, filenames containing newlines, or "{}",
> or which are "--help", and so on, are all rather
> (extremely!) rare — spaces in filenames are much
> more common — and so most of the time can simply
> be ignored, treated as errors, whatever. but,
> if yer writing a script that should be robust,
> (e.g., when you don't have precise control over,
> or knowledge of, the input) these sort of odd
> cases need to be worried about.
>
> cheers!
> -blf-
>
> p.s. incidently, is there any reason for using
> the RE "[ ]" rather than " "? that is, why
> bother with the character class? (I'm ignoring
> that "[" and "]" are _also_ unquoted shell
> metacharacters (which does not, in this case,
> matter?).) the use of an RE character class
> doesn't hurt (AFAIK), but (IM(H?)O) makes the
> RE a tad harder to read, esp. if yer trying
> to untangle whether the square-brackets (and
> curly braces) really are supposed to be shell
> globbing or not ....
>
> --
> ▶ ▶ I AM CURRENTLY LOOKING FOR A JOB! ◀ ◀ | Brian Foster
> Experienced (>25 yrs) software engineer: | Montpellier, FRANCE
> • Unix, Linux, embedded, design-for-test; | Stop E$$o (ExxonMobile)!
> • Software/hardware co-design, debugging; | http:/www.stopesso.com
> • Kernels, drivers, filesystems, &tc; Résumé (CV) & contact details:
> • IDL, automated testing, process, &tc. http://www.blf.utvinternet.ie
> --
> Irish Linux Users' Group mailing list
> About this list : http://mail.linux.ie/mailman/listinfo/ilug
> Who we are : http://www.linux.ie/
> Where we are : http://www.linux.ie/map/
>
--
www.NoToTheDump.org
----------------------------------------------
Ian Spillane
Cork College of Commerce
Morrison's Island, Cork, Ireland
http://www.corkcollegeofcommerce.ie
p +353-21-4222100 f 4275075
More information about the ILUG
mailing list