Re: tricky shell script question
"Erik-Jan Taal" <[EMAIL PROTECTED]> wrote:
> Now watch the terminal where the script was still running. I would
> expect no output to be given, as I assumed the script is read into memory
> at startup and not during execution and this is what happens on most
> systems. On one server however, the 'bla' is echoed.
There are no guarantees here, except that each top-level statement is
entirely read before being executed. Reading beyond the next command
to be executed can vary from one system to another, depending on stdio
buffering from libc. So if you want to be sure that each execution
isn't affected by edits made while it is running, wrap the whole thing
in a compound statement that exits before returning:
#!/bin/sh
{
...
exit
}
paul
tricky shell script question
Hello, Anyone know the answer to this? Suppose the following scenario: Edit new file 'p.sh' in vim. Add these lines : #!/bin/sh sleep 30 Now save the file in vim with ':w' and chmod +x it. Then open another terminal and run the script. While that's sleeping, quickly add the following line to the end of the script: echo bla Now watch the terminal where the script was still running. I would expect no output to be given, as I assumed the script is read into memory at startup and not during execution and this is what happens on most systems. On one server however, the 'bla' is echoed. On another system, which has as far as I can tell the same OS configuration, same version of bash (RHEL ES release 3; bash-2.05b-29.0.3), same options displayed in 'shopt', same output if doing 'lsof | grep p.sh', the script is runs as I initially expected, not outputting the 'bla' and I haven't seen the above mentioned behaviour before in 7 years of working with shell scripts. What is the toggle or switch that makes it output this 'bla' on that particular server or in other words, why is the script being kept open and apparently read line by line? (10 nerd points for those with the right answer ;) Please cc me at this email address as I'm not subscribed to the list. thanks and kind regards, Erik -- Erik Taal ICT Systems Administration, West Midlands Fire Service Streetsbrook Road, Solihull, West Midlands, B91 1QY tel: 0121 380 6572 | fax: 0121 711 1699 mob: 077 6988 1400 (wmfs) | mob: 079 3187 5526 (backup) pag: 076 5975 0398 West Midlands Fire Service Unless expressly stated otherwise, the information contained in this e-mail is confidential and is intended only for the named recipients. You must not copy, distribute, or take any action or reliance upon it. Any unauthorised disclosure of the information contained in this e-mail is strictly prohibited. If you have received it in error please notify us immediately on 0121 380 or return it to mailto:[EMAIL PROTECTED] and then destroy it. The information contained in this e-mail may be subject to public disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure, the confidentiality of this e-mail and your reply cannot be guaranteed. Any opinions expressed in this e-mail (including attachments) are those of the author and do not necessarily reflect the opinions of West Midlands Fire Service. Nothing in this e-mail message amounts to a contractual or other legal commitment on the part of West Midlands Fire Service unless confirmed by a communication signed on behalf of the Chief Fire Officer. West Midlands Fire Service information is available from http://www.wmfs.net This footnote also confirms that this e-mail message has been swept for the presence of computer viruses but does not guarantee that it is free from viruses and you should check all e-mail and attachments with your own anti-virus systems.
Re: Bash 3.2.25 not expanding subscript...
Bernd,
Thank you so very much!!! I would have never figured that out
on my own. I went back to the Advanced Bash Scripting Guide
(by Mendel Cooper) to see if this example would make a good
addition. Searching on your use of Here Strings (e.g. <<<).
I found on page 326 (18.1. Here Strings) a the following method
that also works quite well.
read -r -a FileList <<< $(ls -1)
I wish that I had noticed the Here Strings feature before. That
is a great feature.
Thank you both for your time and contributions!
Regards
Brad
Reference:
Advanced Bash Scripting Guide
http://personal.riverusers.com/~thegrendel/abs-guide.pdf
On Tue, 2008-02-12 at 10:13 +0100, Bernd Eggink wrote:
> Brad Diggs schrieb:
>
> > In short the bug is the result of failure to expand the
> > subscript of an array if the subscript is a variable.
> > The following script should return a list of files with a
> > preceding (File <#>: ). However, it does not work that
> > way because the integer variable (${d}) used in the subscript
> > of the array statement (FileList[${d}]=${File}) does not get
> > properly expanded.
> >
> > #!/bin/bash
> > declare -a FileList=('')
> > declare -i d=0
> >
> > ls -1| while read File
> > do
> >FileList[${d}]=${File}
> >d=$((10#${d}+1))
> > done
>
> This is normal bash behaviour, see FAQ E4. As bash executes _all_ parts
> of a pipe in subshells (in contrast to ksh, where the last component is
> executed in the current shell), the variable 'FileList' being assigned
> here is local to the subshell. After the loop the variable 'FileList'
> declared in line 1 (which happens to have the same name, but that
> doesn't matter) is unchanged.
>
> Try this instead:
>
> while read File
> do
> FileList[d]=$File
> (( d=d+1 ))
> done <<<"$(ls -1)"
>
> Greetings,
> Bernd
--
The Zone Manager
http://TheZoneManager.COM
http://opensolaris.org/os/project/zonemgr
Re: Bash 3.2.25 not expanding subscript...
Brad Diggs schrieb:
In short the bug is the result of failure to expand the
subscript of an array if the subscript is a variable.
The following script should return a list of files with a
preceding (File <#>: ). However, it does not work that
way because the integer variable (${d}) used in the subscript
of the array statement (FileList[${d}]=${File}) does not get
properly expanded.
#!/bin/bash
declare -a FileList=('')
declare -i d=0
ls -1| while read File
do
FileList[${d}]=${File}
d=$((10#${d}+1))
done
This is normal bash behaviour, see FAQ E4. As bash executes _all_ parts
of a pipe in subshells (in contrast to ksh, where the last component is
executed in the current shell), the variable 'FileList' being assigned
here is local to the subshell. After the loop the variable 'FileList'
declared in line 1 (which happens to have the same name, but that
doesn't matter) is unchanged.
Try this instead:
while read File
do
FileList[d]=$File
(( d=d+1 ))
done <<<"$(ls -1)"
Greetings,
Bernd
--
Bernd Eggink
[EMAIL PROTECTED]
http://sudrala.de
