On 2/20/24 4:35 AM, Grisha Levit wrote:
On Mon, Feb 19, 2024 at 5:10 PM Chet Ramey <chet.ra...@case.edu> 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, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
