Re: Documentation issue

2017-10-29 Thread Eli Barzilay
On Sun, Oct 29, 2017 at 10:44 PM, Clark Wang  wrote:
>
> Different people have different expectations which they believe are
> all important.

Yes, and I have already went over this several times: this is an issue
that does confuse people, both ones that I have spoken to and in
tutorial/example/etc pages that come up on top when searching.


> It's not possible to cover so many tricky things in the manual.

It definitely is; it's a tradeoff between things that are worth
mentioning and the size becoming big enough that people won't bother
reading it, hence I tried to suggest a very small change.


> To me the most important thing is to describe the syntax correctly.

This is a non-point.  I obviously don't think that some explanation
should be added *instead* of existing descriptions, or instead of the
current completeness level.


> When you understand the syntax "unset arr[i]" would never surprise
> you.

Again, `unset` has different expectations, because it seems like it
would be a special construct -- since it's dealing with *lvalues*.  Like
I said, the other place where array reference lvalues appear in bash,
assignments, do treat these "lvalue expressions" differently, and even
though it is for a different reason, it makes it easier to get confused
and assume that `unset` is special too.  To summarize:

* In assignments like a[0]=foo, the a[0] part is treated in a special
  way because otherwise it will not be an assignment.  Specifically,
  quoting the whole "a[0]" is not needed, and adding it will break in an
  obvious way.

* In plain variable referendces, $a[0] is wrong anyway, and in ${a[0]}
  there is no need to quote the a[0] since no path expansion is done
  there anyway, and, again, it will break in an obvious way.

* The last kind of reference is unset, and after the above two it is
  reasonable to assume that it *will* be special and will not require
  quoting as well.  That's why I think that a warning that it is not
  special is warranted.

Yet another way to phrase the above: I don't think that you can mess up
these assignments or references with a file like "a0"; but you can do so
for `unset`.

-- 
   ((x=>x(x))(x=>x(x)))  Eli Barzilay:
   http://barzilay.org/  Maze is Life!



${var@Q}: don't quote unless necessary?

2017-10-29 Thread Clark Wang
See following example:

[STEP 100] # echo $BASH_VERSION
4.4.12(2)-release
[STEP 101] # v=abc
[STEP 102] # printf '%q\n' $v
abc
[STEP 103] # printf '%s\n' "${v@Q}"
'abc'
[STEP 104] #

Is it possible to not quote the result since there's no special chars in
the string? I would expect ${var@Q} to produce more concise result compared
to `printf %q' since it's the new syntax. :)

-clark


Re: Documentation issue

2017-10-29 Thread Clark Wang
On Fri, Oct 27, 2017 at 3:28 PM, Eli Barzilay  wrote:

> On Fri, Oct 27, 2017 at 2:37 AM, Clark Wang  wrote:
> >
> > What `unset' does is special but there's nothing special when parsing
> > the command and bash even does not care if it's built-in command or
> > not.
>
> Exactly -- and this kind of a clarification is exactly the thing that
> many people are unaware of.
>
> (And in case it wasn't clear: I said that unset is different in the
> expectations that people have with it, not in how it expands.)
>

Different people have different expectations which they believe are all
important. It's not possible to cover so many tricky things in the manual.
To me the most important thing is to describe the syntax correctly. When
you understand the syntax "unset arr[i]" would never surprise you.


remove empty '' in ${var@Q} result?

2017-10-29 Thread Clark Wang
See following example:

[STEP 100] # echo $BASH_VERSION
4.4.12(2)-release
[STEP 101] # v=\'\'
[STEP 102] # printf '%q\n' "$v"
\'\'
[STEP 103] # printf '%s\n' "${v@Q}"
''\'''\'''
[STEP 104] #


Unexpanded tilde in DIRSTACK[0]

2017-10-29 Thread Steve Jones
While writing a function to save the directory stack as a script, I
noticed that ${DIRSTACK[0]}, the current directory always has the tilde
unexpanded.

This is the same with bash-4.4.12 and bash-4.3.11.

I was wondering if this is an oversight since DIRSTACK[0] is the same as
PWD, or intentional.

Having the tilde expanded for DIRSTACK[ n >= 1 ] but not 0 is an
inconsistency when the rest of the array is even $'...' quoted when
necessary.

-- 
Steve Jones
s...@slohj.org



Re: Documentation issue

2017-10-29 Thread Eli Barzilay
On Fri, Oct 27, 2017 at 2:12 PM, Chet Ramey  wrote:
>
> Let's see if I can find some compromise language that will take care
> of the general case. Since it's a compromise, no one will be
> satisfied, of course.

Thanks -- any improvement would be good.

-- 
   ((x=>x(x))(x=>x(x)))  Eli Barzilay:
   http://barzilay.org/  Maze is Life!