Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS
On Sat, 17 Feb 2024 at 02:32, Chet Ramey wrote: > Let's say we take the approach of restricting attribute changes on readonly > variables to export/trace/local. > > Should it be an error to attempt to set other attributes (it already is > with nameref), or should declare silently ignore it? > I would prefer to make "local" behave as much as possible like a true lexically scoped declaration in "regular" languages. Much as I hate the effect on backwards compatibility, I hate the current situation even more: it's not possible to write a re-usable general-purpose utility function because the function has to avoid overriding outer variables that might differ in their attributes from what the function needs. Arrays and read-only are particularly problematic. So yes please, I'd like "local" to push a new variable definition that inherits nothing from any outer one: not name-ref, not read-only, not array (of any kind), not assignment modifiers (integer, upper-case, lower-case), and above all, not any previous values. Ideally each function invocation would have its own variable namespace, only using the global namespace as a fall-back, but that creates complications with exported variables, so let's take baby steps to get there. Maybe this would be twisting 'local' too much, and it warrants creating a new keyword such as 'var'? -Martin
Re: [PATCH] retry opening startup files on EINTR
On Mon, Feb 19, 2024 at 5:10 PM Chet Ramey wrote: > > On 2/7/24 1:33 AM, Grisha Levit wrote: > > I have some dotfiles symlinked to storage backed by a macOS File > > Provider extension (e.g. Dropbox): > > > > $ realpath ~/.bash_profile > > /Users/levit/Library/CloudStorage/Dropbox/profile/.bash_profile > > > > This normally works fine, except when my terminal emulator (tested > > both Terminal.app and iTerm) restores sessions after being restarted > > -- opening the startup file fails in about half of the restored > > sessions, which ends up looking like: > > > > [Restored Feb 7, 2024 at 00:11:37] > > Last login: Wed Feb 7 00:11:37 on ttys008 > > Restored session: Wed Feb 7 00:11:27 EST 2024 > > -bash: /Users/levit/.bash_profile: Interrupted system call > > mbp:~ levit$ > > > > If I remove ~/.bash_profile, and make ~/.inputrc and ~/.bash_history > > similar symlinks, I see the same issue with loading them (without an > > error message). > > > > I'm not sure what the underlying cause is here, but maybe it would be > > appropriate to retry open(2) calls for these files if they fail with > > EINTR? > > What's the underlying signal here? I hope it's not SIGINT. Looks like it's a SIGWINCH getting sent -- so the Dropbox thing is only relevant in that it makes the open(2) take a while. Reproducible more easily on Linux with: strace -e openat -e inject=openat:signal=SIGWINCH:error=EINTR:when=1 \ -P ~/.bashrc ./bash -i <&- Though a similar test shows that the Readline part of the patch is wrong, and I'm not sure how to solve it, at least without changing existing applications' behavior (and requiring signal setup to happen before rl_initialize or rl_read_init_file are called).
Re: [PATCH] retry opening startup files on EINTR
On Tue, Feb 20, 2024 at 4:35 AM Grisha Levit wrote: > > Though a similar test shows that the Readline part of the patch is wrong, > and I'm not sure how to solve it, at least without changing existing > applications' behavior (and requiring signal setup to happen before > rl_initialize or rl_read_init_file are called). Oh, I guess Readline can just retry reading the file once on EINTR and not do any signal handling on its own.
Re: Bug: Ligatures are removed as one character
It's been a long time since I looked into Unicode, but this is what I remember. Depending on the Unicode normalisation level, backspace is *supposed* to remove a letter and all its associated combining marks. The root problem seems to be that some Arabic letters change from "non-combining" to "combining" depending on the language in which they're used. Unicode also has a problem distinguishing a combining letter (vowel points in Arabic or Hebrew) from a combining diacritic (accents in Latin script). If you think that's a bug in Unicode, you're not alone; the Unicode consortium has been struggling with this for at least ten years - see https://unicode.org/L2/L2014/14109-inline-chars.pdf There's been some progress; Unicode version 12 has at least admitted there's a problem (https://www.unicode.org/versions/Unicode12.1.0/ch07.pdf chapter 7.9 page 327). I'll leave it to others to survey the current state of play with Unicode, but historically it's been a mess. -Martin On Tue, 20 Feb 2024 at 12:26, Avid Seeker wrote: > When pressing backspace on Arabic ligatures (including characters with > diacritics), they are removed as if they are one character. > > Example: > > السَّلامُ > > Pressing 3 backspaces leaves the word at ال. It removed لا which is a > ligature > combining "ل" and "ا", and removed "م" with diacritics. Compare this with > the > behavior of zsh. > > For non-Arabic speakers, this is like typing: fi (U+0046 U+0049), but when > pressing backspace it removed it as the character: fi (U+FB01). > >
Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS
2024年2月20日(火) 18:12 Martin D Kealey : > So yes please, I'd like "local" to push a new variable definition that > inherits nothing from any outer one: not name-ref, not read-only, not array > (of any kind), not assignment modifiers (integer, upper-case, lower-case), > and above all, not any previous values. In my understanding, Bash behaves as you hope from the beginning except for the global readonly variables (2.04+) and the export attribute. I also checked the behavior of old versions now, but Bash seems to behave in that way at least in Bash 2.0. If I'd raise some exceptions, I thought in the past there was a bug that some array attribute or behavior were inherited to a local variable (but don't remember exactly), but that's just a bug found in a very limited situation. Also, the recently added option `shopt -s localvar_inherit' turns on the behavior you hate, but it's not enabled by default. > Ideally each function invocation would have its own variable namespace, > only using the global namespace as a fall-back, That breaks so many existing scripts. > Maybe this would be twisting 'local' too much, and it warrants creating a > new keyword such as 'var'? Perl's `local' is dynamic scoping, but Perl later added `my' for the lexical scoping. Eric Blake suggested `local -s' [1]. Alex xmb suggested `local -L' [2]. [1] https://lists.gnu.org/archive/html/bug-bash/2010-11/msg00036.html [2] https://lists.gnu.org/archive/html/help-bash/2021-05/msg00094.html -- Koichi
Re: [PATCH] retry opening startup files on EINTR
On 2/20/24 4:35 AM, Grisha Levit wrote: On Mon, Feb 19, 2024 at 5:10 PM Chet Ramey wrote: On 2/7/24 1:33 AM, Grisha Levit wrote: I have some dotfiles symlinked to storage backed by a macOS File Provider extension (e.g. Dropbox): $ realpath ~/.bash_profile /Users/levit/Library/CloudStorage/Dropbox/profile/.bash_profile This normally works fine, except when my terminal emulator (tested both Terminal.app and iTerm) restores sessions after being restarted -- opening the startup file fails in about half of the restored sessions, which ends up looking like: [Restored Feb 7, 2024 at 00:11:37] Last login: Wed Feb 7 00:11:37 on ttys008 Restored session: Wed Feb 7 00:11:27 EST 2024 -bash: /Users/levit/.bash_profile: Interrupted system call mbp:~ levit$ If I remove ~/.bash_profile, and make ~/.inputrc and ~/.bash_history similar symlinks, I see the same issue with loading them (without an error message). I'm not sure what the underlying cause is here, but maybe it would be appropriate to retry open(2) calls for these files if they fail with EINTR? What's the underlying signal here? I hope it's not SIGINT. Looks like it's a SIGWINCH getting sent -- so the Dropbox thing is only relevant in that it makes the open(2) take a while. Reproducible more easily on Linux with: strace -e openat -e inject=openat:signal=SIGWINCH:error=EINTR:when=1 \ -P ~/.bashrc ./bash -i <&- Well, depending on when the terminal emulator sends the SIGWINCH, this is probably a bug in Dropbox or the File Provider code. Bash installs its SIGWINCH handler with SA_RESTART, and the default disposition is to discard, so even if a SIGWINCH arrives before bash installs its handler it should not interrupt open(). I suppose we'll have to work around it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Inconsistent treatment of left-hand side of conditional expression where IFS is not its default value
On 2/18/24 5:03 PM, Kerin Millar wrote: Hi, This report stems from the discussion at https://lists.gnu.org/archive/html/help-bash/2024-02/msg00085.html. https://lists.gnu.org/archive/html/help-bash/2024-02/msg00102.html It has to do with ^A appearing in the result of a word expansion in a place where word splitting doesn't occur. It's just just conditional commands; case commands, pattern expansion, and array subscript expansions are other places where word splitting doesn't take place. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] retry opening startup files on EINTR
On Tue, Feb 20, 2024 at 9:18 AM Chet Ramey wrote: > > Well, depending on when the terminal emulator sends the SIGWINCH, this is > probably a bug in Dropbox or the File Provider code. Bash installs its > SIGWINCH handler with SA_RESTART, and the default disposition is to > discard, so even if a SIGWINCH arrives before bash installs its handler it > should not interrupt open(). > > I suppose we'll have to work around it. sigaction(2) says: The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) so I guess a SIGWINCH during the open(2) for ~/.bash_profile, etc. can still get interrupted.
Re: [PATCH] retry opening startup files on EINTR
On 2/20/24 11:37 AM, Grisha Levit wrote: On Tue, Feb 20, 2024 at 9:18 AM Chet Ramey wrote: Well, depending on when the terminal emulator sends the SIGWINCH, this is probably a bug in Dropbox or the File Provider code. Bash installs its SIGWINCH handler with SA_RESTART, and the default disposition is to discard, so even if a SIGWINCH arrives before bash installs its handler it should not interrupt open(). I suppose we'll have to work around it. sigaction(2) says: The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) so I guess a SIGWINCH during the open(2) for ~/.bash_profile, etc. can still get interrupted. I went by POSIX: "This flag affects the behavior of interruptible functions; that is, those specified to fail with errno set to [EINTR]. If set, and a function specified as interruptible is interrupted by this signal, the function shall restart and shall not fail with [EINTR] unless otherwise specified." and POSIX does not otherwise specify for open. But I guess the macOS man page falls under the "otherwise specified" part. Still have to work around it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bash 5.1: Make shell_script_filename available to startup files
On Tue, Feb 20, 2024 at 11:17 AM Chet Ramey wrote:
>
> BASH_SOURCE and BASH_LINENO are part of the debugger support, and exist so
> the debugger can create a function call stack.
>
> I've definitely used them to create my own call stack. I've seen
${BASH_SOURCE[0]} given as preferable to ${0} for figuring out where the
running script is, though I don't recall the details there.
> Since startup files are read before any commands, interactive or non-
> interactive, the name of any shell script isn't in BASH_SOURCE when reading
> the startup files.
>
> Fine.
Re: Bash 5.1: Make shell_script_filename available to startup files
On 2/17/24 6:47 PM, Zachary Santer wrote:
If you're satisfied with $_ or now $0, then fine, but I would actually
expect that to show up as ${BASH_SOURCE[1]} within the ${BASH_ENV} script,
which it obviously doesn't. Don't know what ${BASH_LINENO[0]} ought to be
in that case. Maybe 0?
The way the manual explains BASH_SOURCE and BASH_LINENO is all in
reference to FUNCNAME, which doesn't exist (or is empty) if you're not
executing a function.
BASH_SOURCE and BASH_LINENO are part of the debugger support, and exist so
the debugger can create a function call stack.
Bash pushes the name of a script it's executing to provide a base for the
call stack, but only after it successfully opens it and is ready to read
and execute commands (with the dummy funcname of "main").
`source' changes BASH_SOURCE so you can figure out where functions are
defined and perhaps executed.
Lots of folks define functions they want to use in their startup files,
so executing startup files like .bashrc also modifies BASH_SOURCE to say
which file is currently being read. BASH_ENV works the same way: reading
commands from it puts the name of the file where functions are presumably
being defined and maybe executed into BASH_SOURCE.
Since startup files are read before any commands, interactive or non-
interactive, the name of any shell script isn't in BASH_SOURCE when reading
the startup files.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bash 5.1: Make shell_script_filename available to startup files
On Tue, Feb 20, 2024, 17:53 Zachary Santer wrote:
> On Tue, Feb 20, 2024 at 11:17 AM Chet Ramey wrote:
>
> >
> > BASH_SOURCE and BASH_LINENO are part of the debugger support, and exist
> so
> > the debugger can create a function call stack.
> >
> > I've definitely used them to create my own call stack. I've seen
> ${BASH_SOURCE[0]} given as preferable to ${0} for figuring out where the
> running script is, though I don't recall the details there.
>
check if $BASH_SOURCE begins with a / , else prepend $PWD to it
to path of file
> Since startup files are read before any commands, interactive or non-
> > interactive, the name of any shell script isn't in BASH_SOURCE when
> reading
> > the startup files.
> >
> > Fine.
>
Re: Bash 5.1: Make shell_script_filename available to startup files
On Tue, Feb 20, 2024 at 2:38 PM alex xmb sw ratchev
wrote:
> check if $BASH_SOURCE begins with a / , else prepend $PWD to it
> to path of file
>
source "$( dirname -- "$( realpath --canonicalize-existing --
"${BASH_SOURCE[0]}" )" )\
/common/sourced-file.bash"
What I do, anyway. Won't let symlinks cause issues.
Re: [PATCH] retry opening startup files on EINTR
On Wed, 21 Feb 2024 at 02:37, Grisha Levit wrote: > sigaction(2) says: > > The affected system calls include open(2), read(2), write(2), > sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications > channel or a slow device (such as a terminal, but not a regular file) > > so I guess a SIGWINCH during the open(2) for ~/.bash_profile, etc. can > still get interrupted. > In most cases no, but "regular" files within mounted filesystems that themselves have a "slow" communication channel may be deemed "slow" or "fast" depending on the FS type and the mount options. This is especially true for NFS (on any platform) and FUSE (on Linux); I suspect it affects CIFS but I'd have to check. -Martin
Re: [PATCH] retry opening startup files on EINTR
On 2/20/24 4:51 AM, Grisha Levit wrote: On Tue, Feb 20, 2024 at 4:35 AM Grisha Levit wrote: Though a similar test shows that the Readline part of the patch is wrong, and I'm not sure how to solve it, at least without changing existing applications' behavior (and requiring signal setup to happen before rl_initialize or rl_read_init_file are called). Oh, I guess Readline can just retry reading the file once on EINTR and not do any signal handling on its own. Not unreasonable. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] retry opening startup files on EINTR
On 2/20/24 4:35 AM, Grisha Levit wrote: Though a similar test shows that the Readline part of the patch is wrong, and I'm not sure how to solve it, at least without changing existing applications' behavior (and requiring signal setup to happen before rl_initialize or rl_read_init_file are called). It can still call RL_CHECK_SIGNALS on EINTR, since that function can be called after the signal handlers are installed, in addition to retrying once. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS
On 2/20/24 4:11 AM, Martin D Kealey wrote: So yes please, I'd like "local" to push a new variable definition that inherits nothing from any outer one: not name-ref, not read-only, not array (of any kind), not assignment modifiers (integer, upper-case, lower-case), and above all, not any previous values. You're in luck. Ideally each function invocation would have its own variable namespace, only using the global namespace as a fall-back, but that creates complications with exported variables, so let's take baby steps to get there. That doesn't work with dynamic scoping at all. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH v2] tests/array.tests: using grep -v -e instead of egrep
On 2/19/24 10:32 PM, Xiangyu Chen wrote: From: Xiangyu Chen The console ouput lots of egrep warning message, those message causes test case fail in diff stage. According the message, using grep -v -e instead of egrep. Thanks for the report. I'll put in something; it seems my hand is about to be forced. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
