Re: typeset -p & manpage on it are confusing w/rt funcs
On Thu, Jun 06, 2013 at 03:48:09PM -0700, Linda Walsh wrote:
> I wanted to test to see if a function was defined
imadev:~$ unset foo
imadev:~$ foo=variable
imadev:~$ bar() { echo I am a function; }
imadev:~$ declare -f foo >/dev/null 2>&1 ; echo $?
1
imadev:~$ declare -f bar >/dev/null 2>&1 ; echo $?
0
> and looking at
> typeset in the bash man page, I see
imadev:~$ help typeset
typeset: typeset [-aAfFgilrtux] [-p] name[=value] ...
Set variable values and attributes.
Obsolete. See `help declare'.
But "typeset" does work in place of "declare" in the examples above.
They appear to be interchangeable, for now, in this particular case.
don't just seek to the next line if the script has been edited
Let's say you are running a script that is doing a loop while ... echo Enter name; read name; .. During which the script gets edited on the disk by somebody. Well shouldn't bash, when it goes back to the disk to read some next part of the script, first do some sort of check to tell if the script has changed on disk, instead of the current behavior which apparently is to seek() to the former byte number and execute the next line which now very well might be halfway lodged inside some comment or something.
Re: don't just seek to the next line if the script has been edited
On Fri, Jun 7, 2013 at 3:34 PM, wrote: > Let's say you are running a script that is doing > a loop while ... echo Enter name; read name; .. > > During which the script gets edited on the disk by somebody. > > Well shouldn't bash, when it goes back to the disk to read some next > part of the script, first do some sort of check to tell if the script has > changed on disk, instead of the current behavior which apparently is to > seek() to the former byte number and execute the next line which now > very well might be halfway lodged inside some comment or something. > That has been discussed on help-bash recently http://lists.gnu.org/archive/html/help-bash/2013-05/msg00046.html My opinion is that it's reasonable to have no expectation as to what should happen if you edit a script while it's running. I don't think it's a great idea to slowdown bash to check if, when running from a file, it has changed, or to use non-buffered input .
Re: don't just seek to the next line if the script has been edited
Well OK but sometimes a script could be running for years, during which any change to a file will result in bash executing random bytes... Imagine if you press down on the mouse button meanwhile someone moves the screen up or down... you end up pressing on a different person's face. So I don't see any case where allowing this adds any value to bash. In fact I don't recall any other program with such scary behavior. I mean it's fine with me if bash will execute my script version 1, or my script version 2, but not some mishmosh of random bytes. Surely a little itty bitty check can't slow things that much down. So if I were bash I would bail out "$0 changed on disk. Bailing out rather than executing random bytes."
Re: don't just seek to the next line if the script has been edited
On Fri, Jun 07, 2013 at 09:09:53PM +0800, jida...@jidanni.org wrote: > Well OK but sometimes a script could be running for years, during which > any change to a file will result in bash executing random bytes... This is why you don't edit an installed script in-place. Instead, you move it aside, or remove it, or hardlink it, or do some other fancy thing. # This is the naive way. It is bad because an already-running shell reading # the script as input may get garbled text. Also, there is a period of # vulnerability where the new script is only partially written to disk; # anyone running the script at that time may just get part of it. Finally, # the old script is not preserved, so if the OS crashes during the copy, # you have neither the old one nor the new one. cp myscript /usr/local/bin # This looks better at first glance, and it dodges the problems of mixing # old and new text in an already-running shell, but it leaves a period of # vulnerability where there's no installed script, or where there's a # partially installed script, and it doesn't prevent loss of the old script # if the OS crashes during the copy. So, this is still bad. rm /usr/local/bin/myscript && cp myscript /usr/local/bin # This one is only slightly better. It preserves the old script in case # the OS crashes during the copy, which allows for manual rollback, but # it still leaves that vulnerable period where someone could invoke the # script while it's only partially copied. mv /usr/local/bin/myscript /usr/local/bin/myscript.bak && cp myscript /usr/local/bin # This is better. The mv is atomic, so there is no period of vulnerability # during which the script is either missing or partially installed. cp myscript /usr/local/bin/myscript.tmp && mv /usr/local/bin/myscript.tmp /usr/local/bin/myscript # Alternative, maintaining several installed versions on disk simultaneously. # The installed "script" is really a symlink. The ln is atomic, so this # also avoids all the issues, as long as you never use the same version # number more than once. cp myscript /usr/local/bin/myscript-some.version.number && ln -sf myscript-some.version.number /usr/local/bin/myscript
Re: don't just seek to the next line if the script has been edited
> "GW" == Greg Wooledge writes: GW> On Fri, Jun 07, 2013 at 09:09:53PM +0800, jida...@jidanni.org wrote: >> Well OK but sometimes a script could be running for years, during which >> any change to a file will result in bash executing random bytes... GW> This is why you don't edit an installed script in-place. Instead, you GW> move it aside, or remove it, or hardlink it, or do some other fancy thing. Well it is going to happen anyway, so maybe bash should check by default, and not check if -o risky is set or something. It can't be that expensive.
Re: don't just seek to the next line if the script has been edited
On Fri, Jun 07, 2013 at 10:15:46PM +0800, jida...@jidanni.org wrote: > Well it is going to happen anyway, so maybe bash should check by > default, and not check if -o risky is set or something. It can't be that > expensive. Yes it can. You're talking about adding a ridiculous amount of extra checking and performance penalty to try to avoid users shooting themselves in the foot *on Unix*. As far as I'm concerned, the correct solution is to educate the users instead. I don't speak for Chet, of course.
Re: don't just seek to the next line if the script has been edited
On Fri, 7 Jun 2013 10:19:44 -0400 Greg Wooledge articulated: > Yes it can. You're talking about adding a ridiculous amount of extra > checking and performance penalty to try to avoid users shooting > themselves in the foot *on Unix*. The job of the OS is not to prevent a user from shooting themselves in the foot, but rather to deliver the bullet as efficiently as possible. -- Gerard ✌ ger...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __
Re: don't just seek to the next line if the script has been edited
> "GW" == Greg Wooledge writes: GW> You're talking about adding a ridiculous amount of extra checking GW> and performance penalty to try to avoid users shooting themselves in GW> the foot *on Unix*. I dunno... I thought it might be just reading a couple bytes from where the date is stored before reading a lot more bytes from where the data is stored. But what do I know.
Re: don't just seek to the next line if the script has been edited
On 6/7/13 10:19 AM, Greg Wooledge wrote: > On Fri, Jun 07, 2013 at 10:15:46PM +0800, jida...@jidanni.org wrote: >> Well it is going to happen anyway, so maybe bash should check by >> default, and not check if -o risky is set or something. It can't be that >> expensive. > > Yes it can. You're talking about adding a ridiculous amount of extra > checking and performance penalty to try to avoid users shooting themselves > in the foot *on Unix*. > > As far as I'm concerned, the correct solution is to educate the users > instead. I don't speak for Chet, of course. The current bash behavior is described in http://lists.gnu.org/archive/html/help-bash/2013-05/msg00049.html There are certain obscure cases where this can cause problems on Unix due to parent/child sharing of file offset pointers. I think the correct solution is to retain this behavior where it is required (e.g., when reading a script from the standard input) and to discard it when reading a script from a file. This doesn't directly address the jidanni's concern, but I think the actual occurrence of this problem is infrequent enough to not do anything more elaborate. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: don't just seek to the next line if the script has been edited
On 6/7/13 10:48 AM, Gerard Seibert wrote: > On Fri, 7 Jun 2013 10:19:44 -0400 > Greg Wooledge articulated: > >> Yes it can. You're talking about adding a ridiculous amount of extra >> checking and performance penalty to try to avoid users shooting >> themselves in the foot *on Unix*. > > The job of the OS is not to prevent a user from shooting themselves in > the foot, but rather to deliver the bullet as efficiently as possible. Bash will not stop a user from shooting himself in the foot. If asked, it will obediently load the gun. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Executing shell code on the signal stack, or why is this is a bad idea
On 6/6/13 5:29 AM, Lionel Cons wrote: > Forwarding an interesting posting from Roland Mainz who did an > investigation why signal trap processing in ksh93, bash and dash is > currently not reliable. As I said in a previous message, I have done considerable work between bash-4.2 and bash-4.3 to move signal processing out of signal handlers. This includes running trap commands. The only signal for which bash (and other shells) make a guarantee to execute one instance of a trap for each signal received is SICHLD, and even in that case the guarantee is not exact: the shell will run the trap once for each child that exits. Read the thread beginning at http://lists.gnu.org/archive/html/bug-bash/2012-11/msg3.html for a discussion that kicked off some of the work. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: don't just seek to the next line if the script has been edited
> "CR" == Chet Ramey writes: CR> I think the correct solution is to retain this behavior where it is CR> required (e.g., when reading a script from the standard input) and to CR> discard it when reading a script from a file. This doesn't directly CR> address the jidanni's concern, but I think the actual occurrence of this CR> problem is infrequent enough to not do anything more elaborate. All I know is there I am in emacs seeing things in the output of a running bash script that I want to tweak and get busy tweaking and saving changes before the script finishes, thinking that all this stuff will be effective on the next run of it, when lo and behold now it begins executing random bytes... Yes one can say that these are not C programs and one needs to revise ones expectations, but still I think some parental safety cap is required to keep it from munching random bytes which will always be wrong... such overly dynamic-ness can never be a feature and always be a wild incident unless one gets the alignment just right etc. etc. Anyway my problem is always for scripts on disk and not for the stdin case so maybe I'm covered by the coming changes.
