${var:1:1:=y}

${var:1:1:=y}

[Ray Andrews]

We can of course do this:

     variable=${var:=xy}

I'm wanting the naive expansion of that syntax to do this:

     variable=${var:1:1:=y}

... but it doesn't work. Can something like that be done?
At the moment I'm doing this:

     variable=${var:1:1}
     [ -n "$variable" ] || variable=y

... which is perfectly fine, but the above pseudosyntax would be elegant 
if it could be made workable.


And I found something that puzzles me:


    test ()
    {
       echo $1
       echo ${1:0:1}
       /bin/echo ${1:0:1}
       echo ${1:1:1}
       echo ${1:0:1}${1:1:1}
       echo ${1:1:1}${1:0:1}
    }

    $ test -a

    -a
    [nothing]
    -
    a
    -a
    a-

... If I entered a valid switchofcourse I'd expect that to be eaten
but a solitary dash? Bug?  /bin/echo behaves as I'd expect.

Re: ${var:1:1:=y}

[Lawrence Velázquez]

On Feb 3, 2015, at 6:12 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> We can of course do this:
> 
>    variable=${var:=xy}
> 
> I'm wanting the naive expansion of that syntax to do this:
> 
>    variable=${var:1:1:=y}
> 
> ... but it doesn't work. Can something like that be done?

(This is admittedly a non-answer, as I don't know whether there's a solution that's as succinct as you'd like.)

I would find that syntax (or something like it) very ambiguous. What would be assigned "y" in this case — `var`, or the slice of `var` that you were testing? Neither is obvious.


> At the moment I'm doing this:
> 
>    variable=${var:1:1}
>    [ -n "$variable" ] || variable=y
> 
> ... which is perfectly fine, but the above pseudosyntax would be elegant if it could be made workable.

Wouldn't testing the length of `variable` express your intent better?


> And I found something that puzzles me:
> 
> 
>   test ()
>   {
>      echo $1
>      echo ${1:0:1}
>      /bin/echo ${1:0:1}
>      echo ${1:1:1}
>      echo ${1:0:1}${1:1:1}
>      echo ${1:1:1}${1:0:1}
>   }
> 
>   $ test -a
> 
>   -a
>   [nothing]
>   -
>   a
>   -a
>   a-
> 
> ... If I entered a valid switchofcourse I'd expect that to be eaten
> but a solitary dash? Bug?  /bin/echo behaves as I'd expect.

Test cases should focus on the questionable behavior by discarding irrelevant details. Your case boils down to this:

    % echo -

    % /bin/echo -
    -
    %


vq

Re: ${var:1:1:=y}

[Ray Andrews]

On 02/03/2015 04:18 PM, Lawrence Velázquez wrote:
> On Feb 3, 2015, at 6:12 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>> We can of course do this:
>>
>>     variable=${var:=xy}
>>
>> I'm wanting the naive expansion of that syntax to do this:
>>
>>     variable=${var:1:1:=y}
>>
>> ... but it doesn't work. Can something like that be done?
> (This is admittedly a non-answer, as I don't know whether there's a solution that's as succinct as you'd like.)
>
> I would find that syntax (or something like it) very ambiguous. What would be assigned "y" in this case — `var`, or the slice of `var` that you were testing? Neither is obvious.

Sure, it could end up as a syntactical monster.  I'd  naively read it: 
assign to 'variable' either the value of the second character of 'var' 
(just one character), and if that does not exist, assign 'y'. If you 
were checking for more than one character and some of them existed, but 
some not, then things would get fuzzy indeed.  Probably better left 
alone.  Just asking.

Re: ${var:1:1:=y}

[Lawrence Velázquez]

On Feb 3, 2015, at 7:39 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> I'd naively read it: assign to 'variable' either the value of the second character of 'var' (just one character), and if that does not exist, assign 'y'.

See, that interpretation didn't occur to me at all :)

From zshexpn(1):

    If a ${...} type parameter expression or a $(...) type command
    substitution is used in place of "name" above, it is expanded first
    and the result is used as if it were the value of "name".

So you'd probably want something like this, except with variable
assignment instead of `echo`:

    % foo=
    % echo ${${foo:1:1}:-y}
    y
    % foo=a
    % echo ${${foo:1:1}:-y}
    y
    % foo=abcdef
    % echo ${${foo:1:1}:-y}
    b
    %

vq

Re: ${var:1:1:=y}

[Bart Schaefer]

On Feb 3,  3:12pm, Ray Andrews wrote:
}
} I'm wanting the naive expansion of that syntax to do this:
} 
}      variable=${var:1:1:=y}
} 
} ... but it doesn't work. Can something like that be done?

Jumping several messages ahead:

} assign to 'variable' either the value of the second character of 'var' 
} (just one character), and if that does not exist, assign 'y'

You've forgotten that ${var=val} has the side-effect of assigning to
"var" if it is not set.  I think what you mean is what Lawrence already
demonstrated (again several messages ahead):

    variable=${${var:1:1}:-y}

However, you can do this with subscript syntax:

    variable=${var[2]:=y}

which either assigns to $variable the second character of $var, or
assigns "y" to both $variable and to the second character of $var.

E.g.:

torch% var=a
torch% variable=${var[2]:=y}
torch% typeset -m var\*
variable=y
var=ay
torch% 

You can also do ${var[2]::=z} to forcibly assign "z" to the second
character of $var.

On Feb 3,  7:18pm, Lawrence Velazquez wrote:
} Subject: Re: ${var:1:1:=y}
}
} Test cases should focus on the questionable behavior by discarding
} irrelevant details. Your case boils down to this:
}
}     % echo -
} 
}     % /bin/echo -
}     -
}     %

Yes, the manual says (in the introduction to section 17 Shell Builtin
Commands and at the top of "man zshbuiltins"):

  All builtin commands other than precommand modifiers, even those that
  have no options, can be given the argument `--' to terminate option
  processing.  This indicates that the following words are non-option
  arguments, but is otherwise ignored.  This is useful in cases where
  arguments to the command may begin with `-'.  For historical reasons,
  most builtin commands also recognize a single `-' in a separate word
  for this purpose; note that this is less standard and use of `--' is
  recommended.

(Actually the doc might not say exactly that due to a Yodl formatting
error, but that's what it is supposed to say.  The part about a single
`-' in a separate word is correct and is what matters here.)

Re: ${var:1:1:=y}

[Eric Cook]

On 02/03/2015 10:25 PM, Bart Schaefer wrote:
>   All builtin commands other than precommand modifiers, even those that
>   have no options, can be given the argument `--' to terminate option
>   processing.  This indicates that the following words are non-option
>   arguments, but is otherwise ignored.  This is useful in cases where
>   arguments to the command may begin with `-'.  For historical reasons,
>   most builtin commands also recognize a single `-' in a separate word
>   for this purpose; note that this is less standard and use of `--' is
>   recommended.
printf , test/[, set -A and maybe a few others are exceptions to those
rules.

The "-" and "--" options (was Re: ${var:1:1:=y})

[Bart Schaefer]

On Feb 3, 10:44pm, Eric Cook wrote:
} Subject: Re: ${var:1:1:=y}
}
} On 02/03/2015 10:25 PM, Bart Schaefer wrote:
} >   All builtin commands other than precommand modifiers, even those that
} >   have no options, can be given the argument `--' to terminate option
} >   processing.  [...]  For historical reasons,
} >   most builtin commands also recognize a single `-' in a separate word
} printf , test/[, set -A and maybe a few others are exceptions to those
} rules.

Also "echo" does NOT accept "--" in this way, it ONLY acceps a solitary
"-".  I forget why that is.

printf : accepts -- but not -
test : accepts neither
set : the -A itself ends option processing, and "--" has added semantics

Re: The "-" and "--" options (was Re: ${var:1:1:=y})

[Ray Andrews]

On 02/04/2015 09:10 AM, Bart Schaefer wrote:
> On Feb 3, 10:44pm, Eric Cook wrote:
> } Subject: Re: ${var:1:1:=y}
> }
> } On 02/03/2015 10:25 PM, Bart Schaefer wrote:
> } >   All builtin commands other than precommand modifiers, even those that
> } >   have no options, can be given the argument `--' to terminate option
> } >   processing.  [...]  For historical reasons,
> } >   most builtin commands also recognize a single `-' in a separate word
> } printf , test/[, set -A and maybe a few others are exceptions to those
> } rules.
>
> Also "echo" does NOT accept "--" in this way, it ONLY acceps a solitary
> "-".  I forget why that is.
>
> printf : accepts -- but not -
> test : accepts neither
> set : the -A itself ends option processing, and "--" has added semantics

I'm glad I've been disabused of any notion that consistency is something
to be expected or even valued.  Anyway it seems that this makes it
difficult to echo a dash.  I'd have guessed that single quoting the
dash would work, but no luck, however:

     $ echo '- '

works, so that will do.
>

Re: The "-" and "--" options (was Re: ${var:1:1:=y})

[Lawrence Velázquez]

On Feb 4, 2015, at 12:42 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> I'm glad I've been disabused of any notion that consistency is something
> to be expected or even valued.

As others have opined, expecting "consistency" from any echo(1) is a bad
bet, and there are reasons why zsh's echo doesn't work the way you want
it to. Use printf(1).

> Anyway it seems that this makes it difficult to echo a dash.  I'd have
> guessed that single quoting the dash would work, but no luck, however:
> 
>    $ echo '- '
> 
> works, so that will do.

It "works" because the argument is actually a hyphen followed by
a space. That's why echo doesn't treat it specially. Use this to
print a hyphen:

    % echo - -

Or, again, use printf(1) if you're concerned at all about portability.

vq

Re: The "-" and "--" options (was Re: ${var:1:1:=y})

[Ray Andrews]

On 02/04/2015 03:47 PM, Lawrence Velázquez wrote:
> As others have opined, expecting "consistency" from any echo(1) is a bad
> bet,

Indeed, and as I said, I'm glad I no longer have any expectations there.

> % echo - - 
Ok, the first hyphen gets eaten, and the next one is literal. Still, 
shouldn't
single quotes make anything inside them literal?

Re: The "-" and "--" options (was Re: ${var:1:1:=y})

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

On Wed, Feb 4, 2015 at 5:31 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 02/04/2015 03:47 PM, Lawrence Velázquez wrote:
>
>> % echo - -
>>
> Ok, the first hyphen gets eaten, and the next one is literal. Still,
> shouldn't
> single quotes make anything inside them literal?
>

The single-quotes simply inhibit the shell from performing any
substitutions (e.g., of $var references) inside the quoted string. The
quotes also inhibit splitting the string on $IFS boundaries; i.e., the
shell will pass the resulting string as a single argument to the command.
The echo command simply gets a hyphen whether or not you quoted it. The
echo command has no way of knowing that it was originally enclosed in
single-quotes.

Ignore for the moment that echo might be a shell builtin. Assume it isn't
and the shell has to search $PATH and invoke the first external command of
that name it finds. You certainly don't want the shell to pass '-' to
/bin/echo. If that was done then every external command would need to
implement the same string parsing that the shell already does. And that way
lie madness. In fact, Microsoft Windows works that way. Or at least it did
back in the MS-DOS through Win98  releases. External commands got a single
string representing all the arguments and it was up to the command to split
the string into tokens and handle any quoting. Ugh!


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: The "-" and "--" options (was Re: ${var:1:1:=y})

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On 02/04/2015 05:52 PM, Kurtis Rader wrote:
> On Wed, Feb 4, 2015 at 5:31 PM, Ray Andrews <rayandrews@eastlink.ca 
> <mailto:rayandrews@eastlink.ca>> wrote:
>
>     On 02/04/2015 03:47 PM, Lawrence Velázquez wrote:
>
>         % echo - -
>
>     Ok, the first hyphen gets eaten, and the next one is literal.
>     Still, shouldn't
>     single quotes make anything inside them literal?
>
>
> The single-quotes simply inhibit the shell from performing any 
> substitutions (e.g., of $var references) inside the quoted string. The 
> quotes also inhibit splitting the string on $IFS boundaries; i.e., the 
> shell will pass the resulting string as a single argument to the 
> command. The echo command simply gets a hyphen whether or not you 
> quoted it. The echo command has no way of knowing that it was 
> originally enclosed in single-quotes.

Of course.  I get fuzzified about the handoff from the shell to external
commands.  A bonk on the head and all is clear. Never again.

Re: The "-" and "--" options (was Re: ${var:1:1:=y})

[Bart Schaefer]

On Feb 4,  9:42am, Ray Andrews wrote:
}
} I'm glad I've been disabused of any notion that consistency is something
} to be expected or even valued.

Consistency is both expected and valued.  However, you have prioritized
a different set of values, and thus your expectations are not represented.

Re: The "-" and "--" options (was Re: ${var:1:1:=y})

[Peter Stephenson]

On Wed, 4 Feb 2015 09:10:14 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Also "echo" does NOT accept "--" in this way, it ONLY acceps a solitary
> "-".  I forget why that is.

I think the decision for echo (some years ago) was that it would be
better to make it consistent with versions of /bin/echo rather than with
the normal internal interface, since shell scripts were written to the
external echo interface even if the shell had the builtin.

It seems this argument still works on Linux at least:

% /bin/echo -- foo
-- foo

so I think we were (probably) right and this is the best consistency
we're going to get.

However, there were already incompatible BSD / SYSV echoes even then, so
it was never a full consistency with all possible external command
variants of echo.

pws

Re: The "-" and "--" options (was Re: ${var:1:1:=y})

[ZyX]

04.02.2015, 22:05, "Peter Stephenson" <p.stephenson@samsung.com>:
> On Wed, 4 Feb 2015 09:10:14 -0800
> Bart Schaefer <schaefer@brasslantern.com> wrote:
>>  Also "echo" does NOT accept "--" in this way, it ONLY acceps a solitary
>>  "-".  I forget why that is.
>
> I think the decision for echo (some years ago) was that it would be
> better to make it consistent with versions of /bin/echo rather than with
> the normal internal interface, since shell scripts were written to the
> external echo interface even if the shell had the builtin.
>
> It seems this argument still works on Linux at least:
>
> % /bin/echo -- foo
> -- foo
>
> so I think we were (probably) right and this is the best consistency
> we're going to get.
>
> However, there were already incompatible BSD / SYSV echoes even then, so
> it was never a full consistency with all possible external command
> variants of echo.
>
> pws

`echo` is only usable as long as the option name does not start with a dash and contains no backslashes:

====== test-echo.zsh ======
emulate -L zsh
setopt rcquotes
for shell in zsh bash tcsh fish posh dash bb mksh ksh  ; do
    eval "${shell}_echo() {
              printf 'echo %s' \"\${(j. .)\${(q)@}}\" | $shell
          }"
done
rcsh_echo() {
    printf 'echo %s' "${(j. .)${(qq)@}}" | rcsh
}
for arg in 'a\nb' 'a\\nb' '-E foo' '-e bar' '- baz' '-- bra' ; do
    typeset -A ECHO_RESULTS
    for echofunc in /bin/echo zsh_echo bash_echo tcsh_echo fish_echo posh_echo dash_echo bb_echo mksh_echo ksh_echo rcsh_echo ; do
        echo_result="S$($echofunc $=arg)E"
        ECHO_RESULTS[$echo_result]+="$echofunc "
    done
    printf '>>> %s:\n' "$arg"
    for k in ${(k)ECHO_RESULTS} ; do
        printf '%s: %s\n' "${(qqqq)k}" "${ECHO_RESULTS[$k]}"
    done
    ECHO_RESULTS=()
done
====== /test-echo.zsh ======

====== output ======
>>> a\nb:
$'Sa\nbE': zsh_echo tcsh_echo posh_echo dash_echo mksh_echo 
$'Sa\\nbE': /bin/echo bash_echo fish_echo bb_echo ksh_echo rcsh_echo 
>>> a\\nb:
$'Sa\\nbE': zsh_echo tcsh_echo posh_echo dash_echo mksh_echo 
$'Sa\\\\nbE': /bin/echo bash_echo fish_echo bb_echo ksh_echo rcsh_echo 
>>> -E foo:
$'S-E fooE': tcsh_echo posh_echo dash_echo ksh_echo rcsh_echo 
$'SfooE': /bin/echo zsh_echo bash_echo fish_echo bb_echo mksh_echo 
>>> -e bar:
$'SbarE': /bin/echo zsh_echo bash_echo fish_echo bb_echo mksh_echo ksh_echo 
$'S-e barE': tcsh_echo posh_echo dash_echo rcsh_echo 
>>> - baz:
$'S- bazE': /bin/echo bash_echo tcsh_echo posh_echo dash_echo bb_echo mksh_echo ksh_echo rcsh_echo 
$'SbazE': zsh_echo fish_echo 
>>> -- bra:
$'S-- braE': /bin/echo zsh_echo bash_echo tcsh_echo fish_echo posh_echo dash_echo bb_echo mksh_echo ksh_echo 
$'SbraE': rcsh_echo 
====== /output ======

I do not know which echo zsh behaviour is compatible, but `echo - baz` only shows `baz` in `fish`. All echo versions except rcsh one (this is by Byron Rakitzis’s Plan 9 rc shell reimplementation) (rcsh name is used in Gentoo to prevent conflict with `rc` executable from openrc initialization system) treat `--` as something they need to output, so this part is highly compatible.

Re: ${var:1:1:=y}

[Ray Andrews]

On 02/03/2015 07:25 PM, Bart Schaefer wrote:
> You've forgotten that ${var=val} has the side-effect of assigning to
> "var" if it is not set.

No, it was just irrelevant there.
> I think what you mean is what Lawrence already
> demonstrated (again several messages ahead):
>
>      variable=${${var:1:1}:-y}

Ah, I thought it might be like that, one of those 'nested' things.
Nothing you can't do with those if you know how.
> However, you can do this with subscript syntax:
>
>      variable=${var[2]:=y}
>
> which either assigns to $variable the second character of $var, or
> assigns "y" to both $variable and to the second character of $var.
Even softer.
> You can also do ${var[2]::=z} to forcibly assign "z" to the second
> character of $var.

Excellent.


>
> (Actually the doc might not say exactly that due to a Yodl formatting
> error, but that's what it is supposed to say.  The part about a single
> `-' in a separate word is correct and is what matters here.)
Ok, all good.  Fact is, I'd not have a clue where I'd look to find that 
information.  Thanks both.
>