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
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
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 scrip
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 se
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,
> "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
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
chec
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 thems
> "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 bef
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 talk
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
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 mov
> "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
13 matches
Mail list logo
