Re: Documentation issue
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!
Unexpanded tilde in DIRSTACK[0]
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
remove empty '' in ${var@Q} result?
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] #
Re: Documentation issue
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.
${var@Q}: don't quote unless necessary?
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
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!
