Re: Encoding multiple filenames in a single variable

[Jon Seymour]

Chris, Andrej and Greg,

Thanks for your helpful replies.

You are quite correct on pointing out that the solution does depend on
how it is to be used

To provide more context:

I am working on an extension to git, and need to store a list of shell
files that can be used to extend the capabilities of the command I am
writing. Most of the time, a variable of the form:

GIT_EXTRA_CONDITION_LIBS="libA.sh libB.sh" would work, but technically
speaking, I do need to support spaces in the path (if nothing else,
git's test suite cunningly runs within a directory that contains space
in the name :-).

So, I would like the convenience of using spaces to delimit entries in
the variable since I don't want people to have to define NL variables
in order to extend the variable. On the otherhand, if they do want to
use an inconvenient filename with spaces, there has to be a way to do
it.

In the end, what I have done is make use of git's rev-parse --sq-quote
feature to quote filenames that can contain spaces. That way, if you
really want spaces in the filenames, you can have it, but if you
don't, then you get the convenience of space as a separator.

So, for example:

    GIT_EXTRA_CONDITION_LIBS="libA.sh 'lib B.sh' libC.sh"

I am lucky in that I can assume the existence of git rev-parse on my
path and I am prepared to write the decoding glue in my script.

Anyway, thank you all for your input.

jon.

On Mon, Aug 30, 2010 at 11:07 PM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Sun, Aug 29, 2010 at 04:07:23AM -0400, Chris F.A. Johnson wrote:
>> On Sun, 29 Aug 2010, Jon Seymour wrote:
>>
>> >This isn't strictly a bash question, and I'd prefer a POSIX-only
>> >solution if possible
>
>> >Suppose I need to encode a list of filenames in a variable
>
> POSIX shells won't have arrays (they're allowed to, but they're also
> allowed NOT to, which means you can't count on them being present), but
> you can enlist the positional parameters for use as an array under
> certain conditions.
>
>  set ./*myglob*
>  process "$@"
>
> Of course you don't get bash's full set of capabilities.  You can't
> use range notation to get a "slice" (as some people call it) of an array
> (for the rest of us, that means "from element M to element N"), and
> you can't set or unset individual elements.  Nor can you populate it
> using a loop reading from "find -print0" or similar as you can with a
> bash array.
>
> But if you just need to populate them from a glob, this should suffice.
>
>>    Either separate them with newlines, or (non-POSIX) use an array.
>
> Filenames can also contain newlines, unfortunately.
>
> A third choice would be to store the list of filenames in a file, rather
> than in a variable.  The advantage of this is that you can store NUL
> bytes in a file (unlike in a variable).  The disadvantage is a need for
> platform-specific utilities to create safe temporary files, or for some
> sort of application-level strategy to earmark a safe place to create them
> using primitive-but-portable means.  And of course you'd need some way
> to read them from the file.
>
> It all boils down to exactly what you need to do with the filenames once
> you have them.
>
>