Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

&shell suddenly set to sh instead of bash? #2845

Open
user202729 opened this issue Dec 4, 2023 · 3 comments
Open

&shell suddenly set to sh instead of bash? #2845

user202729 opened this issue Dec 4, 2023 · 3 comments
Labels

Comments

@user202729
Copy link

user202729 commented Dec 4, 2023

Description

While using vimtex, I notice once that &shell is suddenly set to sh. My default setting is bash.

Steps to reproduce

Currently not reproducible, but I suspect it's some sort of race condition in
autoload/vimtex/jobs/vim.vim → vim_unix_run -- maybe if two files attempt to call the function independently, it will break...?

VimtexInfo

Custom fork, actually. Might not be latest version, and I haven't tried reproducing it in latest version.

@user202729 user202729 added the bug label Dec 4, 2023
@lervag
Copy link
Owner

lervag commented Dec 8, 2023

Strange. I believe this is relevant:

let &shell = s:shell
set shellcmdflag& shellquote& shellredir&
silent! call system(a:cmd)
let [ &shell,
\ &shellcmdflag,
\ &shellquote,
\ &shellredir] = s:saveshell
endfunction
" }}}1
function! s:vim_unix_capture(cmd) abort " {{{1
let s:saveshell = [
\ &shell,
\ &shellcmdflag,
\ &shellquote,
\ &shellredir,
\]
let &shell = s:shell
set shellcmdflag& shellquote& shellredir&
silent! let l:output = systemlist(a:cmd)
let [ &shell,
\ &shellcmdflag,
\ &shellquote,
\ &shellredir] = s:saveshell
return v:shell_error == 127 ? ['command not found'] : l:output
endfunction
let s:shell = executable('sh')
\ ? 'sh'
\ : (executable('/usr/bin/sh')
\ ? '/usr/bin/sh' : '/bin/sh')

But it's hard to consider this without being able to reproduce any problems...

@user202729
Copy link
Author

user202729 commented Dec 9, 2023

Anyway the reason why I suspect that is because the time I see that happen, I run :9verb set shell and see that that function is the culprit.

Is there any possibility the function can be called "asynchronously"? (i.e. is there some threading in vimscript?) Because if it's possible, it's certainly possible for two interleaving calls of the function to incorrectly restore the values:

thread A: backup saveshell = &shell (= bash)
thread A: set &shell = sh
thread B: backup saveshell = &shell (= sh)
etc.

then the original value (bash) is lost.


Edit: looks like there's a few calls of timer_start and job_start in the code. I'll see if any of them can cause concurrent execution.

Edit2: With some testing, looks like the call to system() or systemlist() are uninterruptable (even against job_start callback):

function H(channel, msg)
	echom "Callback " .. a:msg
endfunction
function I(job, exit_status)
	echom "Exit"
endfunction

call job_start(["bash", "-c", "sleep 0.5; echo a"], {"out_cb": function('H'), "out_io": "pipe", "exit_cb": function("I")})

echom "Hello"
call systemlist("sleep 2")
echom "Done"

so I'm not sure if it's possible to trigger a race condition this way.

Too bad I don't write down exactly which line causes the problem in the function, but if I recalled correctly it's the latter restoration line (i.e. s:saveshell) -- but either way if the culprit were a former line (i.e. it if the system() call is interrupted and the rest of the function is not executed? Is this possible?) then subsequent call will set s:saveshell to sh anyway.

@lervag
Copy link
Owner

lervag commented Dec 10, 2023

Is there any possibility the function can be called "asynchronously"?

No, I don't think there is. Vimscript does not allow asynchronous stuff.

… i.e. it if the system() call is interrupted and the rest of the function is not executed? Is this possible?

Good question. It may be possible, but it would be very unlikely!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants