Re: redirections preceded by a word with builtins inconsistent

2016-05-23 Thread Dan Douglas 
On Sun, May 22, 2016 at 1:06 PM, Chet Ramey  wrote:
> On 5/21/16 5:16 PM, adonis papaderos wrote:
>
>> Bash Version: 4.3
>> Patch Level: 42
>> Release Status: release
>>
>> Description:
>> When using redirections preceded by a word on builtins
>> 'i.e. : {varname}<&1'
>> the redirection persists to the current shell.
>
> This is by design, and has been discussed previously.  One such discussion
> starts at http://lists.gnu.org/archive/html/bug-bash/2016-01/msg00156.html.
> Maybe it should only do it when preceded by `exec', but it never has.
>
>> Later using {varname}<&- does not close fd.
>
> You don't precede it with an `exec', so it doesn't affect the current
> shell.  So-called `null' commands with redirections are executed in
> subshells.  This is where you need the `exec'.

I know POSIX allows for a subshell but don't know what the point is. I
was confused by this when I first hit it. The subshell isn't obvious.

 $ bash -c 'echo "$BASHPID"
{x[$((pid=BASHPID))$(echo "2: $pid" >&2),0]}<<<"$((pid=BASHPID))$(echo
"1: $pid" >&2)"'
3907
1: 3908
2: 3908
 $ bash -c 'echo "$BASHPID"
{x[$((pid=BASHPID))$(echo "2: $pid" >&2),0]}<<<"$((pid=BASHPID))$(echo
"1: $pid" >&2)"'
3911
1: 3911
2: 3911

ksh being the only other shell that supports auto-fd assignment for
null commands doesn't create one.

 $ bash -c 'typeset -li y=2
{x[y*=2]}<&$((y*=2,0)); typeset -p x y'
bash: line 1: typeset: x: not found
declare -il y="2"
 $ bash -c 'typeset -li y=2
: {x[y*=2]}<&$((y*=2,0)); typeset -p x y'
declare -a x='([8]="10")'
declare -il y="8"
 $ ksh -c 'typeset -li y=2
{x[y*=2]}<&$((y*=2,0)); typeset -p x y'
typeset -a -i x=([8]=11)
typeset -l -i y=8
 $ ksh -c 'typeset -li y=2
: {x[y*=2]}<&$((y*=2,0)); typeset -p x y'
typeset -a -i x=([8]=11)
typeset -l -i y=8

ksh and zsh are hard to test since they do a horrible job parsing the
{fd} in all but trivial cases.

It would be way simpler to only allow redirects at the end of a
command and require each redirect to be a separate word. That
eliminates a ton of ambiguities for {fd}>x, &>x and >&x.

Maybe add a `set -k` work-alike for legacy scripts and people that insist on
`echo >&2 i like surprise redirec{t}

Re: coproc and existing variables

2016-05-23 Thread Grisha Levit 
On Mon, May 23, 2016 at 1:37 PM, Chet Ramey  wrote:

> It's documented as being managed by
> the coproc command, and if you choose to use it yourself, all bets are
> off, similarly to how getopts manages $OPTARG.
>

I see; makes sense.  This does allow unbind arbitrary readonly variables
that end in _PID, but that doesn't really seem like an issue.

Re: nameref subscript assignment with unset target var

2016-05-23 Thread Chet Ramey 
On 5/22/16 6:43 PM, Grisha Levit wrote:
> This multiple-vars-at-same-scope thing happens also happens in the case
> that the nameref points to a variable at a higher scope of the same name as
> the nameref. I suspect this is related to the nameref resolution issue here
> http://lists.gnu.org/archive/html/bug-bash/2016-05/msg00115.html

It doesn't happen any more; the attempt to create the second array `a' is
trapped and rejected.  I'd like to catch the error earlier, though, kind
of like ksh93 does.

-- 
``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: Global variable modification by nameref chain

2016-05-23 Thread Chet Ramey 
On 5/23/16 11:32 AM, Grisha Levit wrote:
> 
> On Sun, May 22, 2016 at 10:08 PM, Chet Ramey  > wrote:
> 
> Should the assignment work?  I'm considering changing the assignments to
> work more like the references.
> 
> 
> I think it would be useful for the assignment to work, as that allows
> functions to take variable names as arguments without worrying about name
> collisions.  Would it also be possible to have the reference resolve the
> same way?  If not, then I suspect consistency in assignments and references
> would be preferable.

I don't like the fact that variable binding simply ignores nameref loops
and treats them the same as the variable not being found.  That's the
difference here.


-- 
``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: coproc and existing variables

2016-05-23 Thread Chet Ramey 
On 5/23/16 12:45 PM, Grisha Levit wrote:
> On Thu, May 19, 2016 at 11:05 AM, Chet Ramey  > wrote:
> 
> >   * The %s_PID variable is unbound unconditionally
> >
> > BTW, this is exploitable for unsetting read-only variables.
> 
> Same change as for getopts.
> 
> This should probably instead be the same change as was previously done for
> unsetting the FD array variable, i.e.:

I disagree.  The idea is that by the time the coproc gets destroyed, the
xxx_PID variable had better be gone.  It's documented as being managed by
the coproc command, and if you choose to use it yourself, all bets are
off, similarly to how getopts manages $OPTARG.  The only question is
whether or not the coproc command should remove any existing variable
before binding it in the first place.

-- 
``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: coproc and existing variables

2016-05-23 Thread Grisha Levit 
On Thu, May 19, 2016 at 11:05 AM, Chet Ramey  wrote:

>   * The %s_PID variable is unbound unconditionally
> >
> > BTW, this is exploitable for unsetting read-only variables.
>
> Same change as for getopts.
>
This should probably instead be the same change as was previously done for
unsetting the FD array variable, i.e.:

diff --git a/execute_cmd.c b/execute_cmd.c
index 09f4772..e9a0b9d 100644--- a/execute_cmd.c+++ b/execute_cmd.c
@@ -2239,7 +2239,7 @@ coproc_unsetvars (cp)
   namevar = xmalloc (l + 16);

   sprintf (namevar, "%s_PID", cp->c_name);-  unbind_variable_noref
(namevar);+  check_unbind_variable (namevar);

 #if defined (ARRAY_VARS)
   check_unbind_variable (cp->c_name);

Otherwise the wrong thing gets unset:

$ declare -n ref_PID=var; coproc ref { :; }; wait; declare -p ref_PID var
[1] 50943
[1]+  Donecoproc ref { :; }
bash: declare: ref_PID: not founddeclare -- var="50943"

​

Re: Global variable modification by nameref chain

2016-05-23 Thread Grisha Levit 
On Sun, May 22, 2016 at 10:08 PM, Chet Ramey  wrote:

> Should the assignment work?  I'm considering changing the assignments to
> work more like the references.
>

I think it would be useful for the assignment to work, as that allows
functions to take variable names as arguments without worrying about name
collisions.  Would it also be possible to have the reference resolve the
same way?  If not, then I suspect consistency in assignments and references
would be preferable.

Re: redirections preceded by a word with builtins inconsistent

2016-05-23 Thread Greg Wooledge 
On Sun, May 22, 2016 at 09:48:47PM +0300, adonis papaderos wrote:
> > > When using redirections preceded by a word on builtins
> > > 'i.e. : {varname}<&1'
> > > the redirection persists to the current shell.

That surprises me, but if Chet says it's not a bug, then so be it.

Simply stop doing it.  It's not good shell code.  If you want to open
or close an FD for the current shell, use exec.

exec {varname}<&1
exec {varname}<&-