On 20/1/2019 19:50, Eduardo A. Bustamante López wrote:
> Changing the behavior of `unset f' to only ever unset variables means
> potentially breaking existing scripts. Is the inconsistency reported severe
> enough to make this change?
The alternative would be to allow anything (that is not a prope
Date:Sun, 20 Jan 2019 17:43:04 -0800
From:don fong
Message-ID:
| i don't see how this helps. the point is to have one file of code that
| behaves differently depending on whether it's dotted in or executed at the
| top level.
That's fine, if you are writing
Date:Sun, 20 Jan 2019 19:50:35 -0800
From:Eduardo =?iso-8859-1?Q?A=2E_Bustamante_L=F3pez?=
Message-ID: <20190121035035.gc31...@system76-pc.vc.shawcable.net>
| Changing the behavior of `unset f' to only ever unset variables means
| potentially breaking existing sc
On Mon, Jan 21, 2019 at 09:26:59AM +0700, Robert Elz wrote:
(...)
> I think his point is that if unset "unset f" (no flags) works to unset
> function f, if f is not a (set) variable, then it should work every time
> "f" is not a set variable, not only the times when the word "f" happens
> to be of
Date:Sun, 20 Jan 2019 16:02:51 -0500
From:Chet Ramey
Message-ID:
| You should not ignore the variable names case. The behavior of unset
| without arguments is to check for a variable first, then optionally
| check for a function name.
That's fine.
| The var
On Mon, Jan 21, 2019 at 10:54 AM Chet Ramey wrote:
>
> On 1/20/19 7:52 AM, Rawiri Blundell wrote:
>
> > So it might be a case of restricting the usability of this change to
> > newer kernels that have dedicated calls like getrandom() or
> > getentropy(), and having to handle detecting/selecting th
>
> Then use the " sh -c '. script' " version instead.
>
i don't see how this helps. the point is to have one file of code that
behaves differently depending on whether it's dotted in or executed at the
top level. the script should do nothing but define stuff when dotted in;
but call the main
On 1/20/19 8:07 PM, Rawiri Blundell wrote:
> */snip*
>
> So it looks like problem solved?
There never was a problem.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tisww
On Mon, Jan 21, 2019 at 1:36 PM Eduardo A. Bustamante López
wrote:
>
> On Sun, Jan 20, 2019 at 05:22:12PM -0500, Chet Ramey wrote:
> > On 1/20/19 4:54 PM, Chet Ramey wrote:
> >
> > >> As an aside, I can confirm the findings of a performance difference
> > >> between 4.4 and 5.0 when running the sc
On 1/21/19 12:25 AM, Chet Ramey wrote:
Isn't there a linker option you can supply, possibly as part of LDFLAGS,
to embed that into the bash binary?
I pass `-Wl,-rpath-link=$instdir/lib' to LDFLAGS. It sets RPATH properly
on all the programs I install (including libreadline, and many other
bas
On Sun, Jan 20, 2019 at 05:22:12PM -0500, Chet Ramey wrote:
> On 1/20/19 4:54 PM, Chet Ramey wrote:
>
> >> As an aside, I can confirm the findings of a performance difference
> >> between 4.4 and 5.0 when running the script provided earlier in the
> >> discussion. At first glance it seems to be du
On 1/20/19 6:28 PM, Mohammad Akhlaghi wrote:
> Yes, I configure Bash using the `--with-installed-readline' and set
> LDFLAGS. It builds and installs successfully and there is no problem in
> that part.
>
> The problem is in running bash. I have installed Bash 5.0 and the
> respective libreadline
Thank you very much for the prompt reply,
On 1/20/19 7:54 PM, Chet Ramey wrote:
On 1/20/19 12:03 PM, Mohammad Akhlaghi wrote:
Dear Bash developers,
I am trying to build Bash for a relatively closed environment where I don't
want the Bash executable to link with the system's libreadline and
lib
On 1/20/19 4:54 PM, Chet Ramey wrote:
>> As an aside, I can confirm the findings of a performance difference
>> between 4.4 and 5.0 when running the script provided earlier in the
>> discussion. At first glance it seems to be due to the switch from the
>> old LCG to the current MINSTD RNG,
>
> T
On 1/20/19 7:52 AM, Rawiri Blundell wrote:
> So it might be a case of restricting the usability of this change to
> newer kernels that have dedicated calls like getrandom() or
> getentropy(), and having to handle detecting/selecting those?
>
> So if this is an exercise that you're happy to entert
On 21.01.2019 00:02, Chet Ramey wrote:
> On 1/20/19 1:46 PM, Andrey Butirsky wrote:
>> I'm not quite understand what exactly is "intentional".
>> The problem is inconsistent behavior of unset '-f' flag for "normal" and
>> "not-normal" function names (I'm not considering conflicting with
>> variable
On 1/20/19 4:03 PM, Andrey Butirsky wrote:
> Chet, the sample was run in normal, not POSIX, mode.
> So it allows '1a' but disallows '1'. Pretty odd.
Yeah, it should not reject all digits when not in posix mode. I'll take
a look there.
--
``The lyf so short, the craft so long to lerne.'' - Chauc
On 1/20/19 1:46 PM, Andrey Butirsky wrote:
> I'm not quite understand what exactly is "intentional".
> The problem is inconsistent behavior of unset '-f' flag for "normal" and
> "not-normal" function names (I'm not considering conflicting with
> variable names case).
You should not ignore the vari
Chet, the sample was run in normal, not POSIX, mode.
So it allows '1a' but disallows '1'. Pretty odd.
On 20.01.2019 23:55, Chet Ramey wrote:
> On 1/20/19 10:46 AM, Andrey Butirsky wrote:
>> `1' is not a valid identifier, still:
>> $ function 1 () { :; }
>> bash: `1': not a valid identifier
>>
>> S
On 1/20/19 1:22 PM, Ilkka Virta wrote:
> The manual could of course mention something about the accepted function
> names, e.g. "Function names can contain the characters [...], except in
> POSIX mode, where they must be valid shell /names/." I'm not exactly sure
> what the accepted characters a
On 1/20/19 10:26 AM, Andrey Butirsky wrote:
> Andreas, I know it will work with the '-f' flag.
> But for others function names, the '-f' unset flag is not required.
> Moreover, it seem confronts with Open Group Base Specification.
When posix mode is enabled, bash restricts function names to valid
On 1/20/19 10:46 AM, Andrey Butirsky wrote:
> `1' is not a valid identifier, still:
> $ function 1 () { :; }
> bash: `1': not a valid identifier
>
> So that is pretty messy..
In posix mode, bash restricts function names to be valid shell identifiers,
as the standard specifies.
--
``The lyf so s
On 1/20/19 12:03 PM, Mohammad Akhlaghi wrote:
> Dear Bash developers,
>
> I am trying to build Bash for a relatively closed environment where I don't
> want the Bash executable to link with the system's libreadline and
> libncursesw, but my own installation of these libraries.
>
> However, even w
On 1/20/19 7:27 AM, Boruch Baum wrote:
> Subject: 5.0: missing documentation for 'wait -f'
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
>
> Compilation CFLAGS: -g -O2
> -fdebug-prefix-map=/build/bash-RVqIBY/bash-5.0=.
>
On Sun, Jan 20, 2019 at 11:05 AM Andrey Butirsky wrote:
>
> Eduardo, the question is about inconsistent, error-prone implementation.
> Not about the workarounds.
What's the error prone part?
- Declare a function name
- Unset it with 'unset -f'
Eduardo, the question is about inconsistent, error-prone implementation.
Not about the workarounds.
On 20.01.2019 21:59, Eduardo Bustamante wrote:
>> The problem is inconsistent behavior of unset '-f' flag for "normal" and
>> "not-normal" function names (I'm not considering conflicting with
>> var
On Sun, Jan 20, 2019 at 10:46 AM Andrey Butirsky wrote:
>
> I'm not quite understand what exactly is "intentional".
Accepting different sets of function names (when POSIX mode is either on/off).
> The problem is inconsistent behavior of unset '-f' flag for "normal" and
> "not-normal" function na
I'm not quite understand what exactly is "intentional".
The problem is inconsistent behavior of unset '-f' flag for "normal" and
"not-normal" function names (I'm not considering conflicting with
variable names case).
This is just confusing and makes the scripts error-prone, IMO.
On 20.01.2019 21:2
On Sun, Jan 20, 2019 at 06:26:43PM +0300, Andrey Butirsky wrote:
> Andreas, I know it will work with the '-f' flag.
> But for others function names, the '-f' unset flag is not required.
> Moreover, it seem confronts with Open Group Base Specification.
> So I consider it as a bug still.
>
It is in
In POSIX mode, Bash disallows names like '1a':
13. Function names must be valid shell names. That is, they may not
contain characters other than letters, digits, and underscores, and may
not start with a digit. Declaring a function with an invalid name
causes a fatal syntax error in non-inter
Dear Bash developers,
I am trying to build Bash for a relatively closed environment where I
don't want the Bash executable to link with the system's libreadline and
libncursesw, but my own installation of these libraries.
However, even when I configure bash with `--enable-rpath', and add
`-W
`1' is not a valid identifier, still:
$ function 1 () { :; }
bash: `1': not a valid identifier
So that is pretty messy..
Bug report: https://savannah.gnu.org/support/?109632
On 20.01.2019 18:26, Andrey Butirsky wrote:
> Andreas, I know it will work with the '-f' flag.
> But for others function
Andreas, I know it will work with the '-f' flag.
But for others function names, the '-f' unset flag is not required.
Moreover, it seem confronts with Open Group Base Specification.
So I consider it as a bug still.
On 20.01.2019 18:18, Andreas Schwab wrote:
> On Jan 20 2019, Andrey Butirsky wrote:
On Jan 20 2019, Andrey Butirsky wrote:
> |$ unset 1a ||
> ||bash: unset: `1a': not a valid identifier
Use `unset -f'.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely differ
Hello,
seems like bash allows illegal function names, but refuses to unset them
then:
|$ function 1a () { :; }||
|
|$ declare -f 1a ||
||1a () ||
||{ ||
|| :||
||}||
|
|$ unset 1a ||
||bash: unset: `1a': not a valid identifier
$
GNU bash, version 4.3.48(1)-release (x86_64-s
Op 19-01-19 om 23:10 schreef Chet Ramey:
> On 1/19/19 2:45 PM, Martijn Dekker wrote:
>> Op 16-01-19 om 02:21 schreef Quentin:
>>> If you really need some quality CSPRNG values, I'd suggest adding a
>>> $SECURE_RANDOM variable that just reads from /dev/urandom.
>>
>> IMHO, this would clearly be the
> OK, this is a reasonable approach. Since /dev/urandom just generates
> random bytes, there's a lot of flexibility and we're not subject to
> any kind of backwards compatibility constraints, especially not the
> 16-bit limit. What do you think would be the best way to present that
> to a user? As
Subject: 5.0: missing documentation for 'wait -f'
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-RVqIBY/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -
38 matches
Mail list logo
