2018-03-05 22:57 GMT+09:00 Greg Wooledge :
> On Sat, Mar 03, 2018 at 08:24:06PM +0900, Koichi Murase wrote:
>> - Note: ksh seems not support local variables. "typeset" in function
>> scopes defines a global variable, and "unset" removes the global
>> variable.
>
> "Real ksh"
Op 05-03-18 om 13:57 schreef Greg Wooledge:
> On Sat, Mar 03, 2018 at 08:24:06PM +0900, Koichi Murase wrote:
>> - Note: ksh seems not support local variables. "typeset" in function
>> scopes defines a global variable, and "unset" removes the global
>> variable.
>
> "Real ksh" has two different
On Sat, Mar 03, 2018 at 08:24:06PM +0900, Koichi Murase wrote:
> - Note: ksh seems not support local variables. "typeset" in function
> scopes defines a global variable, and "unset" removes the global
> variable.
"Real ksh" has two different kinds of functions -- ones declared with
"foo()" and
On 3/3/18 2:23 AM, Robert Elz wrote:
> Date:Fri, 2 Mar 2018 14:43:02 -0500
> From:Chet Ramey
> Message-ID: <4502a0e5-0600-d294-9af2-4e9eeb0a0...@case.edu>
>
> My final comments on this subject:
Mine, too.
>
> | Perhaps. But bash has never
Robert Elz:
> And yet when that change to the entrenched behaviour was made,
> there were no complaints? And there's no option to switch back to
> the previous way? Kind of suggests just how important everyone
> believes the original method was, doesn't it?
doesn't the same argument apply
Hi everyone,
I'm not a member of Bash developers, but I would like to leave
comments as one of Bash users.
--
I don't agree with changing the default behavior that removes the
placeholder of previous-context variables. The reason is just backward
compatibility, but it's important. For
Date:Fri, 2 Mar 2018 14:43:02 -0500
From:Chet Ramey
Message-ID: <4502a0e5-0600-d294-9af2-4e9eeb0a0...@case.edu>
My final comments on this subject:
| Perhaps. But bash has never done this. Not from day one. That's 30 years.
That a bug (be it a
On 2/28/18 5:38 PM, Robert Elz wrote:
> Were I you, I would simply change the "in a previous scope" behaviour to
> match the "in the current scope" behaviour. That makes it consistent,
> and rational.
I can see doing that with the new behavior controlled by a shell option.
Chet
--
``The lyf
On 2/28/18 5:38 PM, Robert Elz wrote:
> I would change "appear" to "be" in the description of the current scope
> behaviour.
Now we're straying into semantics. If the variable were `really' unset,
as opposed to just appearing unset, that could be construed as meaning
the global instance (or any
On 2/28/18 2:00 PM, Robert Elz wrote:
> Date:Wed, 28 Feb 2018 10:27:23 -0500
> From:Chet Ramey
> Message-ID:
>
> | These are two different cases -- same context vs. a previous context. Your
> |
On 3/1/18 8:26 AM, Greg Wooledge wrote:
> On Thu, Mar 01, 2018 at 10:34:30AM +0800, Clark Wang wrote:
>> Look at your answer to my question 6 years ago:
>> http://lists.gnu.org/archive/html/bug-bash/2012-04/msg00186.html
>
> I'm supposed to remember stuff from 6 years ago? Well crap, I'm in
>
On Thu, Mar 01, 2018 at 10:34:30AM +0800, Clark Wang wrote:
> Look at your answer to my question 6 years ago:
> http://lists.gnu.org/archive/html/bug-bash/2012-04/msg00186.html
I'm supposed to remember stuff from 6 years ago? Well crap, I'm in
trouble then.
Seriously, this behavior needs to be
Date:Wed, 28 Feb 2018 15:14:58 -0500
From:Chet Ramey
Message-ID:
| Yes, that's what I said. In the current scope, unset arranges for the
| variable to appear unset. In a previous scope, unset
seems like it would be helpful to explain this behavior more clearly in the
man page.
On Wed, Feb 28, 2018 at 12:14 PM, Chet Ramey wrote:
> On 2/28/18 3:00 PM, Greg Wooledge wrote:
>
> > Does unset create some kind of "placeholder" in the current function
> > (but not in
On 2/28/18 3:00 PM, Greg Wooledge wrote:
> Does unset create some kind of "placeholder" in the current function
> (but not in a caller)?
Yes, that's what I said. In the current scope, unset arranges for the
variable to appear unset. In a previous scope, unset just removes the
variable, which
I think most people will agree that unset is extremely surprising,
though they may point to different parts of it as the source of their
surprise.
8 years after Freddy Vulto's initial investigations, there are many
things I still don't understand. For example, consider this code
straight from
Date:Wed, 28 Feb 2018 10:27:23 -0500
From:Chet Ramey
Message-ID:
| These are two different cases -- same context vs. a previous context. Your
| example is not the same as the original poster's.
On 2/27/18 3:49 PM, Robert Elz wrote:
> Date:Tue, 27 Feb 2018 11:18:40 -0500
> From:Chet Ramey
> Message-ID: <21679c48-4064-5683-2d5f-91bfb7668...@case.edu>
>
> | It doesn't. Run the following script:
>
> OK, that looks good. But now I am
Date:Tue, 27 Feb 2018 11:18:40 -0500
From:Chet Ramey
Message-ID: <21679c48-4064-5683-2d5f-91bfb7668...@case.edu>
| It doesn't. Run the following script:
OK, that looks good. But now I am very confused.
| You'll see that the first expansion
On 2/27/18 11:23 AM, Chet Ramey wrote:
> On 2/26/18 11:34 AM, Robert Elz wrote:
>
>> I believe that most shells that implement local (which is most shells)
>> implement unset of a local as meaning the local var becomes unset,
>> not that it vanishes and the global reappears.
>
> That was the
On 2/26/18 11:34 AM, Robert Elz wrote:
> I believe that most shells that implement local (which is most shells)
> implement unset of a local as meaning the local var becomes unset,
> not that it vanishes and the global reappears.
That was the objection: that unset in a function unset the local
On 2/26/18 9:57 AM, Clint Hepner wrote:
> As you say, the intent is to use a particular value of the variable. The fact
> that unsetting
> IFS causes it to use a default value other than an empty string seems more
> like a concession
> to historical usage than a feature that should be
On 2/26/18 4:31 AM, Robert Elz wrote:
> Date:Mon, 12 Feb 2018 09:26:37 -0500
> From:Chet Ramey
> Message-ID: <790ade74-690f-541c-9ab4-635991744...@case.edu>
>
> | This is bash's dynamic scoping. The visibility of a local variable is
> |
Date:Tue, 27 Feb 2018 10:18:24 +0800
From:Clark Wang
Message-ID:
On Mon, Feb 26, 2018 at 11:07 PM, Greg Wooledge wrote:
> On Mon, Feb 26, 2018 at 09:57:10AM -0500, Clint Hepner wrote:
> > If necessary, you can define a global (at the expense of a single
> subprocess)
> >
> > myIFS=$(printf ' \t\n')
>
> That actually won't work,
Date:Mon, 26 Feb 2018 09:57:10 -0500
From:Clint Hepner
Message-ID:
| As you say, the intent is to use a particular value of the variable. The
fact that unsetting
| IFS causes it to use a
On Mon, Feb 26, 2018 at 09:57:10AM -0500, Clint Hepner wrote:
> If necessary, you can define a global (at the expense of a single subprocess)
>
> myIFS=$(printf ' \t\n')
That actually won't work, because $(...) strips the trailing newline(s).
This might work:
myIFS=$(printf ' \t\nx')
> On 2018 Feb 26 , at 4:31 a, Robert Elz wrote:
>
>Date:Mon, 12 Feb 2018 09:26:37 -0500
>From:Chet Ramey
>Message-ID: <790ade74-690f-541c-9ab4-635991744...@case.edu>
>
> | This is bash's dynamic scoping. The visibility of
Date:Mon, 12 Feb 2018 09:26:37 -0500
From:Chet Ramey
Message-ID: <790ade74-690f-541c-9ab4-635991744...@case.edu>
| This is bash's dynamic scoping. The visibility of a local variable is
| restricted to a function and its children, and `unset'
On 02/12/2018 04:26 PM, Chet Ramey wrote:
On 2/12/18 1:41 AM, Nikolai Kondrashov wrote:
Hi Chet,
On 02/12/2018 01:31 AM, Chet Ramey wrote:
On 2/11/18 1:06 PM, Nikolai Kondrashov wrote:
Hi everyone,
I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
an "unset" of a
On 2/12/18 1:41 AM, Nikolai Kondrashov wrote:
> Hi Chet,
>
> On 02/12/2018 01:31 AM, Chet Ramey wrote:
>> On 2/11/18 1:06 PM, Nikolai Kondrashov wrote:
>>> Hi everyone,
>>>
>>> I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
>>> an "unset" of a global array variable
On 02/12/2018 10:03 AM, Clark Wang wrote:
On Mon, Feb 12, 2018 at 3:23 PM, Nikolai Kondrashov > wrote:
Take a look at these links:
- http://wiki.bash-hackers.org/commands/builtin/unset
On Mon, Feb 12, 2018 at 3:23 PM, Nikolai Kondrashov
wrote:
>
>> Take a look at these links:
>>
>> - http://wiki.bash-hackers.org/commands/builtin/unset
>> - http://www.fvue.nl/wiki/Bash:_Passing_variables_by_reference
>>
>
> Thanks, Clark! However, I find it difficult to
On 02/12/2018 09:06 AM, Clark Wang wrote:
On Mon, Feb 12, 2018 at 2:45 PM, Nikolai Kondrashov > wrote:
On 02/12/2018 08:41 AM, Nikolai Kondrashov wrote:
inner() {
unset res
Oh, and duplicating this line
On Mon, Feb 12, 2018 at 2:45 PM, Nikolai Kondrashov
wrote:
> On 02/12/2018 08:41 AM, Nikolai Kondrashov wrote:
>
>> inner() {
>> unset res
>>
>
> Oh, and duplicating this line fixes the issue.
>
Take a look at these links:
-
On 02/12/2018 08:41 AM, Nikolai Kondrashov wrote:
inner() {
unset res
Oh, and duplicating this line fixes the issue.
Nick
Hi Chet,
On 02/12/2018 01:31 AM, Chet Ramey wrote:
On 2/11/18 1:06 PM, Nikolai Kondrashov wrote:
Hi everyone,
I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
an "unset" of a global array variable doesn't work inside a function, in
"dkms" script from DKMS package.
On 2/11/18 1:06 PM, Nikolai Kondrashov wrote:
> Hi everyone,
>
> I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
> an "unset" of a global array variable doesn't work inside a function, in
> "dkms" script from DKMS package. Adding another "unset" of the same variable
>
Hi everyone,
I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
an "unset" of a global array variable doesn't work inside a function, in
"dkms" script from DKMS package. Adding another "unset" of the same variable
next to it fixes the issue.
Does this sound familiar to
39 matches
Mail list logo