Guys,
I'm either misunderstanding how to control expansion of wildcards on the command line when passing the parameter containing the wildcard as a cli option to a script or the bash controls to allow that are broken. I want to set up a little script alias to search /var/abs for packages and I want the ability to pass either 'name' or 'name*' or '*name*' as input, but if there is anything matching in the current directory, expansion happens before the cli is passed to the script.
Reading, I should be able to turn globbing off with either 'set -f' or 'set -o noglob' and then I should be able to pass the parameter contained a wildcard to the script without any pathname expansion. That appears broken -- or my logic is broken.
From man bash 'set -f' or 'set -o noglob on' should prevent expansion:
set [+abefhkmnptuvxBCEHPT] [+o option] [arg ...] <snip> -f Disable pathname expansion. <snip> -o option-name The option-name can be one of the following: <snip> noglob Same as -f.
EXAMPLE:
touch pacman-foo
then use the following as your test script (tst.sh):
#!/bin/bash
myvar="$1"
printf "Search: %s\n" $myvar
exit 0
Now since i have a file called pacman-foo in my directory trying to pass 'pacman*' should result in expansion before the cli is read resulting in:
00:42 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo
single-quoting doesn't even protect the cli?? :
00:42 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo
Now try 'set -f' to disable pathname expanstion:
01:00 nirvana:~/scr/arch/tmp> set -f 01:02 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo 01:02 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo
Huh? Now try 'set -o noglob'
01:02 nirvana:~/scr/arch/tmp> set -o noglob 01:03 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo 01:04 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo
Huh? Again.. What gives is it bash or is it something I'm reading wrong?
On Thu, Aug 12, 2010 at 11:06 PM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
Guys,
I'm either misunderstanding how to control expansion of wildcards on the command line when passing the parameter containing the wildcard as a cli option to a script or the bash controls to allow that are broken. I want to set up a little script alias to search /var/abs for packages and I want the ability to pass either 'name' or 'name*' or '*name*' as input, but if there is anything matching in the current directory, expansion happens before the cli is passed to the script.
Reading, I should be able to turn globbing off with either 'set -f' or 'set -o noglob' and then I should be able to pass the parameter contained a wildcard to the script without any pathname expansion. That appears broken -- or my logic is broken.
From man bash 'set -f' or 'set -o noglob on' should prevent expansion:
set [+abefhkmnptuvxBCEHPT] [+o option] [arg ...] <snip> -f Disable pathname expansion. <snip> -o option-name The option-name can be one of the following: <snip> noglob Same as -f.
EXAMPLE:
touch pacman-foo
then use the following as your test script (tst.sh):
#!/bin/bash
myvar="$1"
printf "Search: %s\n" $myvar
exit 0
Now since i have a file called pacman-foo in my directory trying to pass 'pacman*' should result in expansion before the cli is read resulting in:
00:42 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo
single-quoting doesn't even protect the cli?? :
00:42 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo
Now try 'set -f' to disable pathname expanstion:
01:00 nirvana:~/scr/arch/tmp> set -f 01:02 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo 01:02 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo
Huh? Now try 'set -o noglob'
01:02 nirvana:~/scr/arch/tmp> set -o noglob 01:03 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo 01:04 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo
Huh? Again.. What gives is it bash or is it something I'm reading wrong?
-- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
quote command arguments like you would normally do.
ie. $ myscript "*pacman*"
On 08/13/2010 01:15 AM, mike rosset wrote:
quote command arguments like you would normally do.
ie. $ myscript "*pacman*"
Nope:
01:32 nirvana:~/scr/arch/tmp> ./tst.sh "pacman*" Search: pacman-foo
On 08/13/2010 01:32 AM, David C. Rankin wrote:
On 08/13/2010 01:15 AM, mike rosset wrote:
quote command arguments like you would normally do.
ie. $ myscript "*pacman*"
Nope:
01:32 nirvana:~/scr/arch/tmp> ./tst.sh "pacman*" Search: pacman-foo
Mike,
I'm sorry, that was a short answer. My thoughts in this situation were that partial or soft-quoting "" would not offer any additional protection that full or hard-quoting '' did not already provide. From ABS:
partial quoting [double quote]. "STRING" preserves (from interpretation) most of the special characters within STRING.
full quoting [single quote]. 'STRING' preserves all special characters within STRING. This is a stronger form of quoting than "STRING".
I'd run across this a couple of days ago on the pacman -Ss reformat script work.
Dave you need to quote your variables ie.
var="*pacman*"; echo "$var"
so printf "Search: %s\n" $myvar should read
printf "Search: %s\n" "$myvar"
On Thu, Aug 12, 2010 at 11:39 PM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 08/13/2010 01:32 AM, David C. Rankin wrote:
On 08/13/2010 01:15 AM, mike rosset wrote:
quote command arguments like you would normally do.
ie. $ myscript "*pacman*"
Nope:
01:32 nirvana:~/scr/arch/tmp> ./tst.sh "pacman*" Search: pacman-foo
Mike,
I'm sorry, that was a short answer. My thoughts in this situation were that partial or soft-quoting "" would not offer any additional protection that full or hard-quoting '' did not already provide. From ABS:
partial quoting [double quote]. "STRING" preserves (from interpretation) most of the special characters within STRING.
full quoting [single quote]. 'STRING' preserves all special characters within STRING. This is a stronger form of quoting than "STRING".
I'd run across this a couple of days ago on the pacman -Ss reformat script work.
-- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Fri, Aug 13, 2010 at 2:10 AM, mike rosset schizoid29@gmail.com wrote:
Dave you need to quote your variables ie.
var="*pacman*"; echo "$var"
so printf "Search: %s\n" $myvar should read
printf "Search: %s\n" "$myvar"
On Thu, Aug 12, 2010 at 11:39 PM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 08/13/2010 01:32 AM, David C. Rankin wrote:
On 08/13/2010 01:15 AM, mike rosset wrote:
quote command arguments like you would normally do.
ie. $ myscript "*pacman*"
Nope:
01:32 nirvana:~/scr/arch/tmp> ./tst.sh "pacman*" Search: pacman-foo
Mike,
I'm sorry, that was a short answer. My thoughts in this situation were that partial or soft-quoting "" would not offer any additional protection that full or hard-quoting '' did not already provide. From ABS:
partial quoting [double quote]. "STRING" preserves (from interpretation) most of the special characters within STRING.
full quoting [single quote]. 'STRING' preserves all special characters within STRING. This is a stronger form of quoting than "STRING".
I'd run across this a couple of days ago on the pacman -Ss reformat script work.
yes what mike said is correct. the best way to remember/catch stuff like this, is to always remember that bash variables are almost pure, direct "text-replacement"; by this i mean the contents of the variable are substituted in place of the variable, and _then_ the expression is evaluated. so, in your case, this line:
printf "Search: %s\n" $myvar
expanded/substituted as:
printf "Search: %s\n" pacman*
which expanded yet again by bash to:
printf "Search: %s\n" pacman-foo
before finally being passed to printf().
C Anthony
On 08/13/2010 02:27 AM, C Anthony Risinger wrote:
On Fri, Aug 13, 2010 at 2:10 AM, mike rossetschizoid29@gmail.com wrote:
Dave you need to quote your variables ie.
var="*pacman*"; echo "$var"
so printf "Search: %s\n" $myvar should read
printf "Search: %s\n" "$myvar"
On Thu, Aug 12, 2010 at 11:39 PM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 08/13/2010 01:32 AM, David C. Rankin wrote:
On 08/13/2010 01:15 AM, mike rosset wrote:
quote command arguments like you would normally do.
ie. $ myscript "*pacman*"
Nope:
01:32 nirvana:~/scr/arch/tmp> ./tst.sh "pacman*" Search: pacman-foo
Mike,
I'm sorry, that was a short answer. My thoughts in this situationwere that partial or soft-quoting "" would not offer any additional protection that full or hard-quoting '' did not already provide. From ABS:
partial quoting [double quote]. "STRING" preserves (from interpretation)most of the special characters within STRING.
full quoting [single quote]. 'STRING' preserves all special characterswithin STRING. This is a stronger form of quoting than "STRING".
I'd run across this a couple of days ago on the pacman -Ss reformatscript work.
yes what mike said is correct. the best way to remember/catch stuff like this, is to always remember that bash variables are almost pure, direct "text-replacement"; by this i mean the contents of the variable are substituted in place of the variable, and _then_ the expression is evaluated. so, in your case, this line:
printf "Search: %s\n" $myvar
expanded/substituted as:
printf "Search: %s\n" pacman*
which expanded yet again by bash to:
printf "Search: %s\n" pacman-foo
before finally being passed to printf().
C Anthony
Guys,
Oh 5h17!! (said while wearing the dunce cap). When at first I got stuck on this, I created a new directory and copied the script into it along with pacman-foo for testing. I had my editor open and the script up via sftp to the server. Some idiot never closed the original script and re-opened the copy of the script in the new tmp subdirectory... So all the quoting, etc. I did, never changed the script I was running :-(
That's it -- I'm going to bed.. Thanks for the help.
P.S. full picture:
Arch Server ----------- editing ================= | me on my |----------------->| original - dir 1| | laptop |---------------\ | | | ----------- running ->| copy in - dir 2| =================
it's good to laugh at yourself every once in a while :p
arch-general@lists.archlinux.org