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
// Under Windows the executable sh is not always available
// If running under MinGW the environment variable SHELL would be set
SHELL:=os.Getenv("SHELL")
// Otherwise use the environment variable COMSPEC (path to cmd.exe)
COMSPEC:=os.Getenv("COMSPEC")
ifSHELL!="" {
shell=SHELL
} elseifCOMSPEC!="" {
shell=COMSPEC
// cmd.exe uses "/c" instead of "-c"
args[0] ="/c"
}
}
cmd:=exec.CommandContext(ctx, shell, args...)
Problem with this, that it uses shell := "sh" always, for unix. Since I run reviewdog in the container I was able to work around the problem with ln -sf /bin/bash /bin/sh but it doesn't feel right to override the global system link and that would be a problem if I needed to do that not in the container.
What do you think about reading the SHELL variable not only for windows but for unix systems as well?
Hey, I faced the issue, when my environment (container) had a default shell of
/bin/ash
, but in the reviewdog command, I needed thebash
features.So I've spent some time trying to make reviewdog use different shell without success until I found the following code:
reviewdog/project/cmdbuilder.go
Lines 32 to 49 in aeef531
Problem with this, that it uses
shell := "sh"
always, for unix. Since I runreviewdog
in the container I was able to work around the problem withln -sf /bin/bash /bin/sh
but it doesn't feel right to override the global system link and that would be a problem if I needed to do that not in the container.What do you think about reading the
SHELL
variable not only forwindows
but forunix
systems as well?Something like:
The text was updated successfully, but these errors were encountered: