Handle different tar options for unpacking

[neven@…]

See "nALFS and Busybox" thread, started by Dermot Bradley. Add an option for "unpacking command".

[kpfleming@…]

Will be factored out into common code, please assign to me.

[neven@…]

Just check out one of the O_STRING options from src/options.c and use it as an example. .nALFSrc needs updating too.

[kpfleming@…]

enhancements committed to CVS

[neven@…]

I suggest some checking of the users' input (options), as playing this much with conversion specifiers (%s) might not be a good idea.

Also, the reason I avoided pipes is because:

unknown_command | tar xv

will return 0.

I don't know if there's a good way to solve that?

But in general, I like it.

[kpfleming@…]

I will look at checking the user's command specifications to do a basic sanity check, but obviously there's only so much we can do.

Also, it appears that you are right, using a pipe like that seems to keep an unknown command from generating a proper status code. I will look into alternatives for that one as well.

Otherwise, glad you like it :-)

[kpfleming@…]

On the subject of the string format specifiers, I can think of two relatively simple solutions:

• go through the user-specified string and prefix all '%' characters that are

not followed by 's' with additional '%', escaping them (also possibly any that occur after the first '%s' combination

• use an alternative string-substitution method (directly coded instead of printf)

Neither of these would be terribly difficult to implement, but I'd hate to set a bad precedent for future nALFS options/etc. that need substitution available.

[kpfleming@…]

sanity checking of user-specified strings now in CVS

I don't think there's anything needed at this point to handle the case where the first command of the pipeline is not found; if the user does that, their build will break anyway, so they'll know something was wrong, and the "not found" message will be in their log. Fixing this would require using shell-specific features, as best I can tell.

[neven@…]

I've created bug 709, so we can close this one.