There could be a small annoyance if you send a script to someone else, your script will assume extglob is set, and it won't work with the default settings.

Too bad bash doesn't have something like Lisp's let, then you could do

Good point; thanks
The closest we get is the illegible and inefficient

What's so hard to understand? I'm simply pointing out that the "set --" command clears all previous positionals before creating new positionals with the new values. If later parts of your script rely on the previous values, they will break.

All the previous values are lost, even the unused $4. That's ok if you don't need them anymore, but what if you do?

As for using "unset" on IFS, I was just playing with this a day or two ago. I'm not sure what's going on with it exactly. The bash man page is unclear on what happens, and whether it returns it to the default value or not. But I ran some tests and it does seem to return to the default <space><tab><newline> behavior. I can't be perfectly sure it returns to the exact same state as before however.

you just have to save them if you want to use them later
Hence the reason why i can't understand why you say positional parameters are being lost (as in lost and can't be retrieved)

Sigh.

I never said that it couldn't be worked around; only that it's something that you need to be aware of. You can't just drop it into an existing script without there being possible ramifications. It's not the "cleanest" solution to the original request.

Besides, it also forces it farther and farther away from the "simple" one-liner, if you need to go to all that trouble to save the old positions.

well, if OP wants to learn bash, then he has to take note of these. For myself, i wouldn't even bother with bash when it comes to parsing text/files

If IFS is unset then a lot of Bash behaves as if IFS had the default value of <space><tab><newline> so many tests are inconclusive about what IFS contains.That's a little obfuscated by endian and padding effects but it take it that 0920 000a (<tab><space><null><newline>) actually denotes <space><tab><newline>

Which is exactly the reason I mentioned it. I was just trying to point out a possible "gotcha" that inexperienced bashers may not realize. I didn't intend for this to turn into a big debate or anything.

But as for "never using bash for text parsing", well, if all you need is to extract a short substring from a variable, then that's usually exactly what you do want to do. In most cases, using a bash built-in is more efficient than calling on an external tool like awk or sed. It's only when the text parsing becomes too complex to do quickly and easily in bash that calling on another tool becomes the better choice.

@catkin: Well, if bash generally behaves the same when IFS is unset as if it were the default, is there any situation in which unsetting it would cause problems? I suppose it would matter if you needed to specifically test for existence of one of the values, but would there be any serious effects otherwise?

Default and unset IFS are functionally identical according to the Open Group's (POSIX) shell definition. GNU's bash reference is not explicit but its section on differences in POSIX mode says nothing about IFS so presumably the default behaviour conforms with POSIX.

I'm going to try it and see if anything breaks.

EDIT:

Clarification: unset is not the same as empty (which is the same as null). Once a variable has been set it can only be unset using the unset command, according to The GNU Bash Reference Manual.