Is it possible to refer to indexes in $@? I can't find any reference to use like the following anywhere in GrayCat's wiki, and the Advanced Scripting Guide and others assign this to a different variable before modifying that instead.

$ echo ${@[0]}
-bash: ${@[0]}: bad substitution

The goal is DRY: The first argument is used for one thing, and the rest for something else, and I'd like to avoid duplicating either the code to normalize, the $@ array, or to create a separate function for this (although at this point it's probably the easiest way out).

Clarification: The object was to modify the values of the variable-length$@ to make the code easier to debug. The current version is a bit too hacky for my liking, although it works even for bizarre paths like

$'--$`\! *@ \a\b\e\E\f\r\t\v\\\"\' \n'

Update: Looks like this isn't possible. The code now uses both code and data duplication, but at least it works:

Bounty goes to anyone who can get rid of the duplication of code to collapse duplicate slashes or duplication of data to hold $1 and the other parameters, or both, while keeping the code a reasonable size and succeeding all the unit tests:

5 Answers
5

POSIX

To normalize the slashes in all the parameters, I'll use the rotating argument trick: shift $1 off, transform it and put the result at the end of the parameter list. If you do that as many time as there are parameters, you've transformed all the parameters, and you've got them back in order.

For the second part of the code, I changed your logic to be less confusing: the outer loop iterates over the parameters, and the inner loop iterates over path components. for x; do … done iterates over the positional parameters, it's a convenient idiom. I use a POSIX-compliant way of matching a string against a pattern: the case construct.

bash, ksh

If you're in bash (or ksh), you can use arrays — I don't understand why you seem to be restricting yourself to the positional parameters. Here's a version that uses an array. I have to admit it's not particularly clearer than the POSIX version, but it does avoid the initial n^2 shuffling.

For the slash normalization part, I use the ksh93 construct ${foo//PATTERN/REPLACEMENT} construct to replace all occurrences of PATTERN in $foo by REPLACEMENT. The pattern is +(\/) to match one or more slash; under bash, shopt -s extglob must be in effect (equivalently, start bash with bash -O extglob). The construct set ${!a[@]} sets the positional parameters to the list of subscripts of the array a. This provides a convenient way to iterate over the elements of the array.

For the second part, I the same loop logic as the POSIX version. This time, I can use [[ … ]] since all the shells targeted here support it.

zsh

Sadly, zsh lacks the ${!array[@]} feature to execute the ksh93 version as-is. Fortunately, zsh has two features that make the first part a breeze. You can index the positional parameters as if they were the @ array, so there's no need to use an intermediate array. And zsh has an array iteration construct: "${(@)array//PATTERN/REPLACEMENT}" performs the pattern replacement on each array element in turn and evaluates to the array of results (confusingly, you do need the double quotes even though the result is multiple words; this is a generalization of "$@"). The second part is essentially unchanged.

ahh... so by 'eval' you meant indirect reference... ${!var} construct is safer, like what I wrote in my answer
–
pepoluanApr 17 '11 at 8:51

@pepoluan ... Thanks for alerting me to that. It's much simpler to write... (I've just now gone back to the webpage I referred to, If I had read further, I would have seen it mentioned it there too :( ....
–
Peter.OApr 19 '11 at 10:27

heh. but if the indirection happens on the left side, eval is a necessary evil, tho' :)
–
pepoluanApr 19 '11 at 11:45

@peopluan...okay, thanks for pointing that out... and just as an aside: I don't understand why eval is considered, by some, to be evil ... (maybe it's because of the spelling :) ... If eval is "bad", then is ${!var} equally "bad"? ... To me it is just part of the language, and a useful part, at that.. but I definitely prefer ${!var} ...
–
Peter.OApr 27 '11 at 2:03