You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
failing to source virtualenvwrapper on alpine linux (ash) #105
${.sh.file} is ksh syntax, but ksh support was dropped in commit d736549 so that branch probably should've been taken out too.
That still won't help your shell, though, because without a default VIRTUALENVWRAPPER_SCRIPT won't get set.
Really, using $0 should probably be the default -- that will even work in Bash, under most cases, although $BASH_SOURCE is certainly better if it's available.
Although, interestingly, when sourcing a script it seems that $0 is the ONLY thing that works for Zsh, and $BASH_SOURCE is the only thing that works for Bash.
so I guess the first question is, if you save this script to a file test_arg0.sh:
echo"0: $0"echo"BASH_SOURCE: ${BASH_SOURCE}"echo"ZSH_ARGZERO: ${ZSH_ARGZERO}"echo"ZSH_SCRIPT: ${ZSH_SCRIPT}"# Feel free to add any additional variables# your shell's documentation indicates might be useful.
Then what do you get in ash for each of these scenarios?
@DHELLMAN See #117, though I don't know whether that's a complete solution. It at least gives ash and others like it a fighting chance, by no longer defaulting to KSH syntax for all shells that aren't Bash or Zsh.
Conclusion: None of the existing methods will work for Ash. $0 shows us the wrong path. So we need to look for other supported options.
Looking at the man page, I don't see any documented method of determining the path where a sourced script is located. $0 is all it supports, and that remains the path to the shell binary.
Activity
agowa commentedon Sep 2, 2024
May be the same issue as with fish shell however I've not tried it there. Just guessing from the surrounding code.
#100
ferdnyc commentedon Mar 24, 2025
${.sh.file}is ksh syntax, but ksh support was dropped in commit d736549 so that branch probably should've been taken out too.That still won't help your shell, though, because without a default
VIRTUALENVWRAPPER_SCRIPTwon't get set.Really, using
$0should probably be the default -- that will even work in Bash, under most cases, although$BASH_SOURCEis certainly better if it's available.ferdnyc commentedon Mar 24, 2025
Although, interestingly, when sourcing a script it seems that
$0is the ONLY thing that works for Zsh, and$BASH_SOURCEis the only thing that works for Bash.so I guess the first question is, if you save this script to a file
test_arg0.sh:Then what do you get in
ashfor each of these scenarios?ashshell prompt):source test_arg0.shHere's what I get
Zsh
$ zsh test_arg0.sh 0: test_arg0.sh BASH_SOURCE: ZSH_ARGZERO: test_arg0.sh ZSH_SCRIPT: test_arg0.sh $ source test_arg0.sh 0: test_arg0.sh BASH_SOURCE: ZSH_ARGZERO: zsh ZSH_SCRIPT:Bash
$ bash test_arg0.sh 0: test_arg0.sh BASH_SOURCE: test_arg0.sh ZSH_ARGZERO: ZSH_SCRIPT: $ source test_arg0.sh 0: bash BASH_SOURCE: test_arg0.sh ZSH_ARGZERO: ZSH_SCRIPT:Set VIRTUALENVWRAPPER_SCRIPT portably
ferdnyc commentedon Mar 24, 2025
I don't think fish is ever gonna work. It dumps out with an error anytime a variable reference uses curly braces! (What are they THINKING??)
dhellmann commentedon Mar 29, 2025
I think there's an alternative implementation for fish.
I've never heard of the ash shell. If its syntax can be supported without breaking anything, I could review patches.
ferdnyc commentedon Mar 30, 2025
@DHELLMAN See #117, though I don't know whether that's a complete solution. It at least gives
ashand others like it a fighting chance, by no longer defaulting to KSH syntax for all shells that aren't Bash or Zsh.Set VIRTUALENVWRAPPER_SCRIPT portably
Set VIRTUALENVWRAPPER_SCRIPT portably
ferdnyc commentedon Mar 31, 2025
I just remembered that alpine publishes docker containers, which makes it really easy to test the
ashshell on a different system. So...Conclusion: None of the existing methods will work for Ash.
$0shows us the wrong path. So we need to look for other supported options.Looking at the man page, I don't see any documented method of determining the path where a sourced script is located.
$0is all it supports, and that remains the path to the shell binary.ferdnyc commentedon Mar 31, 2025
Ah, crap, that's my fault, I shouldn't have marked that PR as "fixes" this issue, since it doesn't.
...Thanks, you beat me to it.
ferdnyc commentedon Mar 31, 2025
I've posted a StackExchange question asking how this might be solved.
(Very belated update: StackExchange produced nothing other than additional confirmation that it doesn't seem to be possible.)