[arch-general] scripts to analyze and manage /var/cache/pacman/pkg for installed/uninstalled & gen install scr for uninstalled

David C. Rankin drankinatty at suddenlinkmail.com
Tue Dec 8 23:52:27 EST 2009


Crouse wrote:
> In the event of a sudden termination event for the program, it would
> be nice to have a check there.
> Look into "trap" and make sure no matter what your IFS gets set back
> to it's original value
> even if someone does a CTRL+ALT+DEL.  ;)
> 
> Dave Crouse
> 
> 
Dave,

	Thank you. I know trap. There is no need to reset IFS when run in a script 
(see my comments in the script, "It's just good form". Why? When you execute a 
script, it gets its own environment (a subshell so to speak) and nothing that 
happens in a subshell can effect the current environment. For example, do this:

03:15 alchemy:~> echo "'$IFS'"
'
'
  (That's ' \t\n' [space,tab,newline] by default)

	Now let's change IFS in a subshell [ any command executed enclosed in 
parenthesis on the command line gets its own subshell ], confirm the change, 
then check the current environment:

22:44 alchemy:~> ( IFS='$__'; echo "'$IFS'" ); echo "'$IFS'"
'$__'
'
'

	You can see that the IFS set and echoed in the subshell remained the $__ that 
was assigned, but the second echo of IFS after the subshell terminated is still 
the familiar old ' \t\n', That's when you don't need to reset it in a script, 
but that is also why I do it anyway in the scripts and I write the comments in 
the scripts telling you it isn't necessary but to do it anyway as a matter of 
good form. Very few understand the subshell rule, but if you always reset IFS, 
you will always be OK :p

	Thanks for making me remember it though!

-- 
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


More information about the arch-general mailing list