The stupid question is the question not asked | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Gold star (or ++ points in monk-speak :-)).
I wondered about that semicolon and the order of processing things -- my only concern (in some 'general' case, not my particular problem) about using "\n" might be portability to a platform where "\n" wasn't the line delimiter.... I should have just "tried it". I too am minorly surprised that '/bin/sh' allows the the non-posix extensions... Definitely not something to rely on... Another solution that I ran across was to use bash as a 'filter' of sorts: It sorta *bums* me that 'semicolon' isn't equivalent to '\n' in this case. There might be a bug there, somehow: if "shopt cmdhist"=on, then bash tries to store multiline commands in one history entry. Then, if "shopt lithist" is off (I think that's default), then bash will store multi-line commands separated by a semicolon (instead of the newline which would have separated the commands of the multi-line command). As you point out, this isn't equivalent to separation by a newline.
It would be a rare error case, but if one concocted a multi-line command that turned on 'extglob'bing, followed by its usage, then that multi-line command sequence would be stored with semi-colons, so on recall, it would contain the non-working semi's instead of the requisite newlines... (and people wonder how it is that I so often break things...:-) ) In reply to Re^4: getting shell expansion to work
by perl-diddler
|
|