Re: Issue declaring an array via a variable name
On Sat, Aug 21, 2021, at 6:02 PM, Hunter Wittenborn wrote:
> In my head, something like this (where 'value' is equal to 'y'):
>
> `declare "${value}"="x"`
>
> becomes this (which it appears to do so):
>
> `declare "y"="x"`
Almost. The argument parses without issue ('=' has no special
meaning here), so it undergoes the usual parameter expansion and
quote removal, and you end up with
declare y=x
which is fine.
> Logically (for me anyway), this:
>
> `declare "${value}"=("x" "z")`
>
> should then become this:
>
> `declare "y"=("x" "z")`
The shell performs parameter expansion and quote removal on a command
*after* parsing it. As I see it, your mental model for `declare`
requires the shell to:
1. Pause parsing upon seeing '('.
2. Go back and, out of the usual order, perform parameter expansion
and quote removal on the portion of the word preceding '=' to
see whether it expands to a valid identifier.
3a. If it does, resume parsing the word as an assignment, so '('
begins an array.
3b. If not, resume parsing as regular word, so '(' is a syntax error.
These would be rules that don't apply anywhere else. You may find
this logical and worthwhile, but others sure don't.
"${value}"=("x" "z") # invalid
echo "${value}"=("x" "z") # invalid
declare "${value}"=("x" "z") # invalid but you want it to be valid
As has already been pointed out, this all goes away if you just
quote the parentheses -- even if you're silly about it:
declare -a "${value}"=\(x\ z\)
--
vq
Re: Issue declaring an array via a variable name
i wrote, i write again
declare "var=value"
not
declare "var"="value"
On Sun, Aug 22, 2021, 00:02 Hunter Wittenborn
wrote:
> > As an end user I would expect the unquoted `('
>
> > operator to cause a syntax error, just as it does in `echo ('.
>
>
>
> Well I'm expecting '(' to be part of the shell's syntax (when unquoted; so
> likewise not cause a syntax error), but when looking at things like the
> left side of a variable assignment, I'm sure you'll agree that it should
> allow any string that fits a variable's normal specification (regardless of
> being an array or not).
>
>
>
> Maybe this will explain how I'm thinking about it:
>
>
>
> In my head, something like this (where 'value' is equal to 'y'):
>
>
>
> `declare "${value}"="x"`
>
>
>
> becomes this (which it appears to do so):
>
>
>
> `declare "y"="x"`
>
>
>
> Logically (for me anyway), this:
>
>
>
> `declare "${value}"=("x" "z")`
>
>
>
> should then become this:
>
>
>
> `declare "y"=("x" "z")`
>
Re: Issue declaring an array via a variable name
> As an end user I would expect the unquoted `('
> operator to cause a syntax error, just as it does in `echo ('.
Well I'm expecting '(' to be part of the shell's syntax (when unquoted; so
likewise not cause a syntax error), but when looking at things like the left
side of a variable assignment, I'm sure you'll agree that it should allow any
string that fits a variable's normal specification (regardless of being an
array or not).
Maybe this will explain how I'm thinking about it:
In my head, something like this (where 'value' is equal to 'y'):
`declare "${value}"="x"`
becomes this (which it appears to do so):
`declare "y"="x"`
Logically (for me anyway), this:
`declare "${value}"=("x" "z")`
should then become this:
`declare "y"=("x" "z")`
Re: Exclamation mark when using character classes
> On Fri, Aug 20, 2021 at 10:30 PM hancooper via Bug reports for the GNU
> Bourne Again SHell bug-bash@gnu.org wrote:
>
> I am using EPOCHREALTIME and then computing the corresponding human
> readable form, that can handle
> changes in locale
> now=$EPOCHREALTIME
> printf -v second '%(%S)T.%s' "${now%[^[:digit:]]}" "${now#[^[:digit:]]}"
> printf -v minute '%(%M)T' "${now%[^[:digit:]]}"
> printf -v hour '%(%H)T' "${now%[^[:digit:]]}"Incidentally, [![:digit:]] does
> not work there, you need to use the
> POSIX-specified caret (^) instead of an
> exclamation mark when using character classes. I'm not sure if this is
> intentional or a bug in bash; man
> page doesn't seem to mention it.
https://lists.gnu.org/archive/html/help-bash/2021-08/msg00120.html
> On Aug 21, 2021, at 10:55 AM, hancooper wrote:
>
> I got it backwards. POSIX specifies ! for use in globs, and bash
> permits ^ as an extension, for people who are used to ^ from regular
> expressions.
>
> Had "tested" this using grep or [[ =~ ]] or something else that uses
> regular expressions, not globs.
https://lists.gnu.org/archive/html/help-bash/2021-08/msg00125.html
Why are you reposting other people's messages from a different
mailing list, without attribution?
--
vq
Re: EPOCHREALTIME does not behave correctly before 1970
Date:Sat, 21 Aug 2021 07:28:23 +0200 From:Emanuele Torre Message-ID: | I have also read that gettimeofday() is considered obsolete and is | deprecated by POSIX. It is being removed as a required interface, but it still exists everywhere (and will for a very long time, since so much uses it) and is just fine if microsecond accuracy is good enough (which it is for a shell script), and is easily the most portable interface when better accuracy than just seconds is needed (when seconds are good enough, time() is even more portable). This also is 100% irrelevant to the issue you raised, which is not particularly important, as no-one is likely to be running bash in 1969 or earlier (it didn't exist then) - so unless you've invented time travel, in any real situation, the real time cannot be before the epoch. kre
Exclamation mark when using character classes
‐‐‐ Original Message ‐‐‐
On Saturday, August 21, 2021 11:25 AM, Ilkka Virta wrote:
> What do you get with [![:digit:]] then? It seems to work the same with both
> ! and ^ here:
>
> $ now=$EPOCHREALTIME
> $ echo "${now%[^[:digit:]]}" "${now#[^[:digit:]]}"
> 1629544775 183030
> $ echo "${now%[![:digit:]]}" "${now#[![:digit:]]}"
> 1629544775 183030
>
> On Fri, Aug 20, 2021 at 10:30 PM hancooper via Bug reports for the GNU
> Bourne Again SHell bug-bash@gnu.org wrote:
>
> > I am using EPOCHREALTIME and then computing the corresponding human
> > readable form, that can handle
> > changes in locale
> > now=$EPOCHREALTIME
> > printf -v second '%(%S)T.%s' "${now%[^[:digit:]]}" "${now#[^[:digit:]]}"
> > printf -v minute '%(%M)T' "${now%[^[:digit:]]}"
> > printf -v hour '%(%H)T' "${now%[^[:digit:]]}"Incidentally, [![:digit:]]
> > does not work there, you need to use the
> > POSIX-specified caret (^) instead of an
> > exclamation mark when using character classes. I'm not sure if this is
> > intentional or a bug in bash; man
> > page doesn't seem to mention it.
I got it backwards. POSIX specifies ! for use in globs, and bash
permits ^ as an extension, for people who are used to ^ from regular
expressions.
Had "tested" this using grep or [[ =~ ]] or something else that uses
regular expressions, not globs.
EPOCHREALTIME does not behave correctly before 1970
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/
uname output: Linux t420 5.10.54-1-lts #1 SMP Wed, 28 Jul 2021
15:05:20 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 8
Release Status: release
Description:
> static SHELL_VAR *
> get_epochrealtime (var)
> SHELL_VAR *var;
> {
>char buf[32];
>char *p;
>struct timeval tv;
>
>gettimeofday (, NULL);
>snprintf (buf, sizeof (buf), "%u%c%06u", (unsigned)tv.tv_sec,
> locale_decpoint (),
> (unsigned)tv.tv_usec);
>
>p = savestring (buf);
>FREE (value_cell (var));
>var_setvalue (var, p);
>return (var);
> }
get_epochrealtime() casts tv.tv_sec (a time_t a.k.a. int) to unsigned
int causing EPOCHREALTIME to not behave correctly before the Unix Epoch.
> APPLICATION USAGE
> Applications should use the clock_gettime() function instead of the
> obsolescent gettimeofday() function.
> [...]
> FUTURE DIRECTIONS
> The gettimeofday() function may be removed in a future version.
> [...]
> Issue 7
> The gettimeofday() function is marked obsolescent.
I have also read that gettimeofday() is considered obsolete and is
deprecated by POSIX.
See:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html
Repeat-By:
$ faketime 1969-01-01 bash -c 'declare -p EPOCHSECONDS EPOCHREALTIME'
declare -- EPOCHSECONDS="-31539600"
declare -- EPOCHREALTIME="4263427696.758887"
Re: Exclamation mark when using character classes
What do you get with [![:digit:]] then? It seems to work the same with both
! and ^ here:
$ now=$EPOCHREALTIME
$ echo "${now%[^[:digit:]]*}" "${now#*[^[:digit:]]}"
1629544775 183030
$ echo "${now%[![:digit:]]*}" "${now#*[![:digit:]]}"
1629544775 183030
On Fri, Aug 20, 2021 at 10:30 PM hancooper via Bug reports for the GNU
Bourne Again SHell wrote:
> I am using EPOCHREALTIME and then computing the corresponding human
> readable form, that can handle
> changes in locale
>
> now=$EPOCHREALTIME
> printf -v second '%(%S)T.%s' "${now%[^[:digit:]]*}" "${now#*[^[:digit:]]}"
> printf -v minute '%(%M)T' "${now%[^[:digit:]]*}"
> printf -v hour '%(%H)T' "${now%[^[:digit:]]*}"
>
> Incidentally, [![:digit:]] does not work there, you need to use the
> POSIX-specified caret (^) instead of an
> exclamation mark when using character classes. I'm not sure if this is
> intentional or a bug in bash; man
> page doesn't seem to mention it.
