Skip to content

Commit fcbd59c

Browse files
committed
cabal-install: don't pass exe name to external commands
Previously the executable name of the external command was passed to external commands as the first argument. This behaviour was adapated from cargo which does this because of reasons that are internal to rust that do not affect GHC Haskell, and are even orthogonal to patterns that see common use in Haskell. Additionally, it complicates the 'simple' case which is what we should optimize for when building such a feature. The previous use case (one executable that serves multiple external subcommands) is still possible by the following means: - using a wrapper around the executable - using a symlink and check argv[0] in the executable Additionally, the variable `$CABAL` that was set by `cabal-install` was renamed to `CABAL_EXTERNAL_CABAL_PATH`. This has two reasons: 1. it makes migration easier for users of the external command feature that were previously expecting the name of the executable to appear in `argv[1]` 2. it does not unnecessarily pollute the environment variable namespace as it turns out some other tools have been and are already using this name, historically Resolves #10275
1 parent 1e3c355 commit fcbd59c

File tree

7 files changed

+46
-13
lines changed

7 files changed

+46
-13
lines changed

cabal-install/src/Distribution/Client/Main.hs

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -372,17 +372,20 @@ mainWorker args = do
372372
-> [String]
373373
-> IO (CommandParse Action)
374374
delegateToExternal commands' name cmdArgs = do
375+
-- we rely on cabal's implementation of findProgramOnSearchPath not following
376+
-- symlinks here. If that ever happens, then the argv[0] of the called executable
377+
-- will be different to the intended one and will break tools that work by reading it.
375378
mCommand <- findProgramOnSearchPath normal defaultProgramSearchPath ("cabal-" <> name)
376379
case mCommand of
377-
Just (exec, _) -> return (CommandReadyToGo $ \_ -> callExternal exec name cmdArgs)
380+
Just (exec, _) -> return (CommandReadyToGo $ \_ -> callExternal exec cmdArgs)
378381
Nothing -> defaultCommandFallback commands' name cmdArgs
379382

380-
callExternal :: String -> String -> [String] -> IO ()
381-
callExternal exec name cmdArgs = do
383+
callExternal :: String -> [String] -> IO ()
384+
callExternal exec cmdArgs = do
382385
cur_env <- getEnvironment
383386
cabal_exe <- getExecutablePath
384-
let new_env = ("CABAL", cabal_exe) : cur_env
385-
result <- try $ createProcess ((proc exec (name : cmdArgs)){env = Just new_env})
387+
let new_env = ("CABAL_EXTERNAL_CABAL_PATH", cabal_exe) : cur_env
388+
result <- try $ createProcess ((proc exec cmdArgs){env = Just new_env})
386389
case result of
387390
Left ex -> printErrors ["Error executing external command: " ++ show (ex :: SomeException)]
388391
Right (_, _, _, ph) -> waitForProcess ph >>= exitWith

cabal-testsuite/PackageTests/ExternalCommand/cabal.test.hs

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,6 @@ main = do
1717
addToPath (takeDirectory exe_path) $ do
1818
-- Test that the thing works at all
1919
res <- cabal_raw_action ["aaaa"] (\h -> () <$ Process.waitForProcess h)
20-
assertOutputContains "aaaa" res
2120

2221
-- Test that the extra arguments are passed on
2322
res <- cabal_raw_action ["aaaa", "--foobaz"] (\h -> () <$ Process.waitForProcess h)

cabal-testsuite/PackageTests/ExternalCommandEnv/setup-test/AAAA.hs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ import System.Environment
44
import System.Process
55

66
main = do
7-
cabal_proc <- getEnv "CABAL"
7+
cabal_proc <- getEnv "CABAL_EXTERNAL_CABAL_PATH"
88
other_var <- getEnv "OTHER_VAR"
99
putStrLn ("OTHER_VAR is set to: " ++ other_var)
1010
callProcess cabal_proc ["--version"]

cabal-testsuite/PackageTests/ExternalCommandExitCode/cabal.test.hs

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,6 @@ main = do
1818
addToPath (takeDirectory exe_path) $ do
1919
-- Test that the thing works at all
2020
res <- fails $ cabal_raw_action ["aaaa"] (\h -> () <$ Process.waitForProcess h)
21-
assertOutputContains "aaaa" res
2221
-- Check the exit code is the one returned by subcommand
2322
unless (resultExitCode res == ExitFailure 99) (assertFailure $ "Incorrect exit code: " ++ show (resultExitCode res))
2423

cabal-testsuite/PackageTests/ExternalCommandHelp/setup-test/AAAA.hs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,5 +5,5 @@ import System.Environment
55
main = do
66
args <- getArgs
77
case args of
8-
["aaaa" , "--help"] -> putStrLn "I am helping with the aaaa command"
8+
["--help"] -> putStrLn "I am helping with the aaaa command"
99
_ -> putStrLn "aaaa"

changelog.d/pr-11232.md

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
---
2+
synopsis: don't pass exe name to external commands
3+
packages: [cabal-install]
4+
prs: 11232
5+
issues: [10275]
6+
significance: significant
7+
---
8+
9+
Previously the executable name of the external command was passed to external commands as the first argument.
10+
11+
This behaviour was adapted from cargo which does this because of reasons that are internal to rust that do not affect GHC Haskell, and are even orthogonal to patterns that see common use in Haskell.
12+
13+
Additionally, it complicates the 'simple' case which is what we should optimize for when building such a feature - with this change, for any executable `cabal-foo` in your search-path, `cabal foo` will be a valid invocation of that command.
14+
15+
The previous use case (one executable that serves multiple external subcommands) is still possible by the following means:
16+
17+
- using a wrapper around the executable
18+
- using a symlink and check argv\[0\] in the executable
19+
20+
Additionally, the variable `$CABAL` that was set by `cabal-install` was renamed to `CABAL_EXTERNAL_CABAL_PATH`. This has two reasons:
21+
1. it makes migration easier for users of the external command feature that were previously expecting the name of the executable
22+
to appear in `argv[1]`
23+
2. it does not unnecessarily pollute the environment variable namespace as it turns out some other tools have been and are already
24+
using this name, historically

doc/external-commands.rst

Lines changed: 12 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -3,19 +3,27 @@ External Commands
33

44
``cabal-install`` provides a system for external commands, akin to the ones used by tools like ``git`` or ``cargo``.
55

6-
If you execute ``cabal <cmd>``, ``cabal-install`` will search the path for an executable named ``cabal-<cmd>`` and execute it. The name of the command is passed as the first argument and
7-
the remaining arguments are passed afterwards. An error will be thrown in case the custom command is not found. The exit code of cabal when calling an external command is the same as the exit code
6+
If you execute ``cabal <cmd>``, ``cabal-install`` will search the path for an executable named ``cabal-<cmd>`` and execute it. An error will be thrown in case the custom command is not found. The exit code of cabal when calling an external command is the same as the exit code
87
of the command.
98

10-
The ``$CABAL`` environment variable is set to the path of the ``cabal-install`` executable
9+
The name of the command is *not* passed as the first argument as it is done in cargo, instead you will have to figure out the name via `argv[0]` as
10+
is the case in e.g. `git`.
11+
12+
The ``$CABAL_EXTERNAL_CABAL_PATH`` environment variable is set to the path of the ``cabal-install`` executable
1113
which invoked the subcommand.
1214

1315
It is strongly recommended that you implement your custom commands by calling the
14-
CLI via the ``$CABAL`` variable rather than linking against the ``Cabal`` library.
16+
CLI via the ``$CABAL_EXTERNAL_CABAL_PATH`` variable rather than linking against the ``Cabal`` library.
1517
There is no guarantee that the subcommand will link against the same version of the
1618
``Cabal`` library as ``cabal-install`` so it would lead to unexpected results and
1719
incompatibilities.
1820

21+
Historically, the `cabal-install` binary would pass the name of the executable which it is trying to invoke via the external command feature as
22+
the first argument to the executable itself. The main difference was that ``$CABAL_EXTERNAL_CABAL_PATH`` was called ``$CABAL``, which means that
23+
you can stay compatible with both versions, depending on which variable is set.
24+
25+
Mind that if you were implementing external commands previously, you will not need to skip the first argument (the executable name) anymore.
26+
1927
``cabal-install`` can also display the help message of the external command.
2028
When ``cabal help <cmd>`` is invoked, then ``cabal-<cmd> <cmd> --help`` will be called so
2129
your external command can display a help message.

0 commit comments

Comments
 (0)