On 07/30/2014 07:48 PM, Chet Ramey wrote:
> On 7/30/14, 2:44 PM, Notes Jonny wrote:
>> On 7 Jul 2014 19:47, "Eric Blake" wrote:
>>>
>>> On 07/07/2014 12:34 PM, Chris Down wrote:
Hi Jon,
As is standard with other buitins, umask is documented at `help umask`:
>>>
>>> That said, POSIX
On Wed, Jul 30, 2014 at 02:46:08PM -0700, Linda Walsh wrote:
> I just noticed in the 4.2.45 I'm still running that when I
> reset my local to standard (LC_ALL=C), it turned off
> "vi mode" in my shell ops and turned on emacs mode.
I cannot reproduce this.
imadev:~$ bash-4.2
imadev:~$ echo $BASH_V
On 7/30/14, 6:11 PM, Linda Walsh wrote:
> If I assigned the read-only bit to an exported var and run a new
> shell, that var is still read-only.
No:
$ ./bash ./x24
4.2.47(4)-release
foo = one
foo = two
$ cat ./x24
echo $BASH_VERSION
foo=one
readonly foo
export foo
./bash -c 'echo foo = $foo ; f
> but it seemed to work and not be at fault upon further
> exploration. Now it's one of 2 Associative arrays (often
> called "'map's" in the code where they are used as such)
> that is failing due to illegal subscript messages.
>
> The fact that one of the maps works and the other does not
> see
On 7/30/14, 8:18 PM, Linda Walsh wrote:
> Was comparing /contrasting output of "which" with output of "type -[pPa]"
> (trying all 3) with the intent of being able to turn which into an alias,
> since
> it returned incorrect info for "builtins, aliases and functions" -- because
> it is a separate pr
Chet Ramey wrote:
On 7/30/14, 6:11 PM, Linda Walsh wrote:
If I assigned the read-only bit to an exported var and run a new
shell, that var is still read-only.
No:
$ ./bash ./x24
4.2.47(4)-release
foo = one
foo = two
$ cat ./x24
echo $BASH_VERSION
foo=one
readonly foo
export foo
./bash -c
Greg Wooledge wrote:
On Wed, Jul 30, 2014 at 02:46:08PM -0700, Linda Walsh wrote:
I just noticed in the 4.2.45 I'm still running that when I
reset my local to standard (LC_ALL=C), it turned off
"vi mode" in my shell ops and turned on emacs mode.
I cannot reproduce this.
Try "unsetting LC_A
On Thu, Jul 31, 2014 at 07:51:01AM -0700, Linda Walsh wrote:
> Chet Ramey wrote:
> >$ ./bash ./x24
> >4.2.47(4)-release
> >foo = one
> >foo = two
> >$ cat ./x24
> >echo $BASH_VERSION
> >
> >foo=one
> >readonly foo
> >export foo
> >
> >./bash -c 'echo foo = $foo ; foo=two ; echo foo = $foo'
>
> Whe
On Thu, Jul 31, 2014 at 07:54:33AM -0700, Linda Walsh wrote:
> Greg Wooledge wrote:
> >On Wed, Jul 30, 2014 at 02:46:08PM -0700, Linda Walsh wrote:
> >>I just noticed in the 4.2.45 I'm still running that when I
> >>reset my local to standard (LC_ALL=C), it turned off
> >>"vi mode" in my shell ops a
Chet Ramey wrote:
but it seemed to work and not be at fault upon further
exploration. Now it's one of 2 Associative arrays (often
called "'map's" in the code where they are used as such)
that is failing due to illegal subscript messages.
The fact that one of the maps works and the other doe
Hello there,
Commit 43aebe922bc2a614c410e282fdf772e063454168 added an empty file
named '-i' at the root of the Bash repo. This might be an elaborate
trick to auto-add the -i flag to all commands run with * as argument in
the repo directory, or a mistake.
Just thought I'd mention it in case it's t
On 7/31/14, 7:08 AM, Quentin Minster wrote:
>
> Hello there,
>
> Commit 43aebe922bc2a614c410e282fdf772e063454168 added an empty file
> named '-i' at the root of the Bash repo. This might be an elaborate
> trick to auto-add the -i flag to all commands run with * as argument in
> the repo directory
On 7/31/14, 10:51 AM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> On 7/30/14, 6:11 PM, Linda Walsh wrote:
>>> If I assigned the read-only bit to an exported var and run a new
>>> shell, that var is still read-only.
>>
>> No:
>>
>> $ ./bash ./x24
>> 4.2.47(4)-release
>> foo = one
>> foo = two
>>
On Thu, 31 Jul 2014, Chet Ramey wrote:
On 7/31/14, 10:51 AM, Linda Walsh wrote:
...
I thought the idea of RO vars being passed to children was considered
desirable?
As Greg says, there's no existing mechanism to do that using the
environment, which is the only way to communicate across exec(2
On 7/31/14, 3:36 PM, Chris F.A. Johnson wrote:
> On Thu, 31 Jul 2014, Chet Ramey wrote:
>> On 7/31/14, 10:51 AM, Linda Walsh wrote:
> ...
>>> I thought the idea of RO vars being passed to children was considered
>>> desirable?
>>
>> As Greg says, there's no existing mechanism to do that using the
>
Chet Ramey wrote:
On 7/31/14, 10:55 AM, Linda Walsh wrote:
Chet Ramey wrote:
On 7/30/14, 8:18 PM, Linda Walsh wrote:
Was comparing /contrasting output of "which" with output of "type -[pPa]"
(trying all 3) with the intent of being able to turn which into an alias,
since
it returned incorrec
Greg Wooledge wrote:
On Thu, Jul 31, 2014 at 07:51:01AM -0700, Linda Walsh wrote:
Chet Ramey wrote:
$ ./bash ./x24
4.2.47(4)-release
foo = one
foo = two
$ cat ./x24
echo $BASH_VERSION
foo=one
readonly foo
export foo
./bash -c 'echo foo = $foo ; foo=two ; echo foo = $foo'
When did that chan
Chet Ramey wrote:
type -P echo
ls -l $(type -P echo)
If you already have `echo' in the command hash table, type -P will return
it, since that's what the shell will attempt to execute.
---
It's not in the hash table, but type -P still
returns the non-executable.
Ishtar:/> ll {,/usr
18 matches
Mail list logo
