Case (in)sensitivity of complete -X patterns?
Hello, I was looking for a way to make complete/compgen -X filter patterns case insensitive, but it seems that the -X patterns are not affected by nocaseglob nor nocasematch, is that correct? If yes, would it be possible to add something that would accomplish that in future bash releases?
Sourcing a script renders getopts impotent (or is it just me?)
Hi, Platform : Red Hat Enterprise Linux v5.5 Bash : GNU bash, version 4.1.0(1)-release (x86_64-unknown-linux-gnu) I have a script which uses getopts that I need to source in my interactive shell. The problem is that if I source it, getops behaves as if no arguments were passed into the script. Although, if I simply run the script in a sub-process, getopts works correctly. As an experiment, I echo'd all args prior to the getopts statement in the script, and when the script was sourced all args were correctly displayed. So I'm at a loss as to why getopts doesn't seem to work when the script is sourced. On a side note, there is some error checking being done within the script. I would like the script execution to terminate but leave the interactive shell running upon error detection (i.e., don't exit out of the terminal sessioni). Is there any way to accomplish that objective in bash? Regards, -- Mun
Re: Sourcing a script renders getopts impotent (or is it just me?)
Use return instead of exit when you have an error and you're sourcing the script. You can make it conditional. Try setting OPTIND=1 to make your script work when it's sourced. Initialize your script's variables since they will be carried over between runs when you source the script. #!/bin/bash invoked=$_ # needs to be first thing in the script OPTIND=1# also remember to initialize your flags and other variables . . .# do some stuff if some error condition then if [[ $invoked != $0 ]] then return 1# the script was sourced else exit 1# the script was executed fi fi On Thu, Sep 16, 2010 at 4:06 PM, Mun wrote: > Hi, > > Platform : Red Hat Enterprise Linux v5.5 > Bash : GNU bash, version 4.1.0(1)-release (x86_64-unknown-linux-gnu) > > I have a script which uses getopts that I need to source in my > interactive shell. The problem is that if I source it, getops behaves > as if no arguments were passed into the script. Although, if I simply > run the script in a sub-process, getopts works correctly. > > As an experiment, I echo'd all args prior to the getopts statement in > the script, and when the script was sourced all args were correctly > displayed. So I'm at a loss as to why getopts doesn't seem to work when > the script is sourced. > > On a side note, there is some error checking being done within the > script. I would like the script execution to terminate but leave the > interactive shell running upon error detection (i.e., don't exit out of > the terminal sessioni). Is there any way to accomplish that objective > in bash? > > Regards, > > -- > Mun > >
RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Why do (or should) double quotes lose their normal meaning inside double brackets? I would like to see double quotes and single quotes NOT disable RE functionality when used with =~. I would like to suggest that to disable RE functionality, that the user use '==', instead. Wouldn't it be reasonable to do RE matching when one does =~ and not do it when one uses ==? Either that, or perhaps reversing the sense with == and quotes, so that if you use double/single quotes with ==, then it does an REGEX match. (right!) As ludicrous as that sounds -- having double or single quoted strings be special cased with =~ makes as much sense. The whole point of the =~ was to allow regex matching. If you don't want it, why would you have to create special, asymmetric functionality for quotes?
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Linda Walsh wrote: Why do (or should) double quotes lose their normal meaning inside double brackets? After initialĺy introducing =~, Chet made it consistent with =/== in a second version, means: =/== doesn't do pattern matching for parts inside quotes, =~ doesn't du regexp matching for parts inside quotes. My personal opinion is: This makes sense. Can't speak for others. That's also the reason you have 2 different =~ behaviours. Please, whatever the reasonable result of this discussion is, do not make up yet the next =~ variant that's incompatible with the others ;) I would like to see double quotes and single quotes NOT disable RE functionality when used with =~. I would like to suggest that to disable RE functionality, that the user use '==', instead. == is the same as =, my suggestion is to NOT touch that. It would be even better to introduce a new operator instead of touching =~ (see above) or the pattern matchers. Maybe you don't care for compatiblity, I do, since I'm operating the same scripts on systems with Bash 2.05b to the newest 4.x without changes - so please don't suggest anything that will break compatiblity with very common things that were there for ages (like the pattern matchers in the conditional expression). Wouldn't it be reasonable to do RE matching when one does =~ and not do it when one uses ==? For ==, see above. For the behaviour of =~: It was adjusted in 3.2 to be consistent with =/==. As far as I remember there was a lot of discussion, maybe Chet can say something about it. The whole point of the =~ was to allow regex matching. If you don't want it, why would you have to create special, asymmetric functionality for quotes? I don't really see your problem with regex matching at the moment, maybe I misunderstand you. Maybe you think this means you can not match quotes in a regex at all, this would be totally wrong, of course you can. Just with a small syntax speciality (like for pattern matching, too). The "portable" way for =~ in Bash is putting the RE into a variable, anyways. Not nice. Such things come up when you break compatiblity (see above, changed between 3.0 and 3.2). Regards, Jan
