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 part
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 re
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
i
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 scrip
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?
