Correctly parsing the -e command line argument

[ofseed]

ghostty currently cannot correctly parse (or say in the same way as other terminals) the command line argument -e, which leads to a common case where setting it as the default terminal via xdg-terminal-exec fails to open a file with a path that contains spaces or parentheses when using nvim.desktop as the default editor.

Reproduction Steps

Situation 1

Pass a parameter with spaces to ghostty -e, such as a path with spaces

ghostty -e nvim "path with spaces"

Expected Behavior

nvim opens a file at "path with spaces".

Actual Behavior

Open the three files "path", "with", and "spaces" in nvim.

Situation 2

Pass a parameter with parentheses to ghostty -e, for example

ghostty -e nvim "path with ()"

Expected Behavior

nvim opens the file "path with ()"

Actual Behavior

/bin/sh: -c: line 1: syntax error near unexpected token `('
/bin/sh: -c: line 1: `nvim path with ()'

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ghostty failed to launch the requested command:

/bin/sh -c nvim path with ()

Runtime: 15 ms
Exit Code: 2

Press any key to close the window.

[mitchellh]

Fully supportive of figuring out some answer to this. I've converted to a planning discussion until we have an actionable result that we want to take. I also want to note there is some discussion already in a previous PR at #2620.

I'll use this comment to provide additional background:

I've maintained multiple widely used projects in the past that do shell parsing, and it becomes a very hairy nightmare really quickly. My goal with Ghostty's command and -e features are that they have straightforward, well-defined cases they work and don't work. I don't have a strong opinion where those edges are, except that maintainability is key.

Second point of background: Ghostty originally didn't support args at all. You can probably use git blame to find the issue that brought this but originally we only allowed single executables to completely bypass this problem. This was unliked for somewhat obvious reasons, but it had very clear semantics at least.

My attempt to just use /bin/sh -c was to avoid shell parsing (hence passing the command through a shell to do the shell parsing). This breaks for the cases noted in the original post.

I'm mostly curious how other terminals do it. Note we can't copy the source of a GPL licensed project so we have to be careful, but if anyone can conceptually explain how they work we can mimic that behavior if we find it maintainable.

[c-wicklein]

After some thought and work on #3030, I'm going to back pedal and suggest that in the balance, accepting the single argument following the -e switch as the command to run makes more sense than allowing the command to span multiple arguments, but my reasoning is also tied to #3030.

If Ghostty were to execute the alternative command with e.g. execv, as it does now, then what's proposed here would make things simpler, and the thorny problem would be how to specify a multi-argument command in the configuration file. However, were Ghosty to do what's proposed in #3030 and treat the alternative command as a simple sequence of bytes (i.e a string) to send to the user's shell, then the configuration file is no longer a problem, and if Ghostty accepted a multi-argument alternative command on the command line, it would be necessary to join those arguments into a single string, respecting the quoting conventions of the user's shell. Boo. So, in that world, it makes far more sense for the command line argument -e to be followed by a single string which can be written to the user's shell, and the problem of quoting to create multi-argument commands is handed back to the user.

For a (contrived) example...

dir="/Users/me/Music and Movies"
ghostty -e "ls '-lart' '$dir'"

...passes Ghosty a single string, ls '-lart' '/Users/me/Music and Movies', which Ghostty could write to the user's shell, without having to understand quoting.

[ManuelSchneid3r]

This effectively will not allow to run a command in ghostty without a shell. This is probably not what users would expect. and opens the door for tons of side effects. is this really necessary? if people want to have a shell in between they could still run eg ghostty -- /bin/sh -c htop.

[c-wicklein]

@ManuelSchneid3r A fundamental concern is that there are two methods of specifying an alternative command. One (ghostty's command line) is conducive to accepting a vector of arguments; the other (in the configuration file) is not. Is it okay for -e and command to be different in this way?

[ManuelSchneid3r]

okay for what/whom?

[c-wicklein]

Having two different mechanisms for specifying an alternative command, a command line switch -e and the configuration file parameter command, where their semantics appear to differ (the former accepting multiple arguments and the latter accepting a single string) was bothering me. Having stewed on it a bit, though, I think this is a small harm, if it's a harm at all, and it's more important that each mechanism work in an independently sane way. For the command line switch -e, I'm back to thinking that the xterm model where -e must be last and a vector of arguments follows is appropriate. For the configuration file parameter command, I still think executing a login instance of the user's login shell and writing the command to that shell rather than attempting to "execute" the command should be supported (ala Terminal.app on macOS.)

[SHU-red]

Hi there,
trying to use ghosty with shortcuts to open and execute a bash-script, taking a single argument but it does not seem to work

this works

~/Scripts/FuzzyExecute.sh ~/Scripts

this errors

ghostty -e "~/Scripts/FuzzyExecute.sh ~/Scripts"

Error in second terminal window

/bin/sh: line 1: /home/shured/Scripts/FuzzyExecute.sh: No such file or directory

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ghostty failed to launch the requested command:

/bin/sh -c ~/Scripts/FuzzyExecute.sh ~/Scripts

Runtime: 2 ms
Exit Code: 127

Press any key to close the window (although the file exists)

Not sure if its OK to add to this post of if the root cause belongs to a different issue/PR/discussion

[SHU-red]

I found a bit of a hacky solution for me (not being an expert)
Somehow by utilizing fish -c inbetween i got my script running but passing ~/Scripts as argument did not work
So i changed my script using Env-Vars

So the main takeaway here is that i start a new fish shell via ghostty to run my bash script successfully
Below from my hyprland.conf because i need this as "quick start" script

bind = $mainMod, Y, exec, export FE_DIR=/home/shured/Scripts; $terminal -e fish -c "~/Scripts/FuzzyExecute/FuzzyExecute.sh"

Maybe not helpful for you but in case yes i wanted to write it down

Thanks

[m4r1vs]

alacritty -e "echo hi fails since echo is a shell built in and not an executable. It seems like other terms behave similarly.
If I want the terminal to launch the command with a shell, I would expect the user to pass in the shell to the argument explicitly.

I would strongly welcome it if ghostty also did not launch everything through /bin/sh (or cmd.exe) but just implemented parsing of the given command properly.

@mitchellh Maybe we could use something like wordexp for POSIX and CommandLineToArgvW on windows?

[m4r1vs]

Note:

❯ gnome-terminal -e "ls"
# Option “-e” is deprecated and might be removed in a later version of gnome-terminal.
# Use “-- ” to terminate the options and put the command line to execute after it.

[m4r1vs]

❯ gnome-terminal -- "echo $SHELL"
# Error: Failed to execute child process “echo /usr/bin/zsh”: Failed to execve: No such file or directory

[m4r1vs]

However

❯ gnome-terminal -- echo $SHELL
❯

[m4r1vs]

Experimenting with wordexp here and currently running this branch which works for my needs.

[mitchellh]

The implementation of wordexp in libc on macOS execs out to perl, and in musl and gnu libc it execs out to /bin/sh. I'm not quite sure that's a nice improvement over what we're doing, although it does punt it to someone else's problem. 😆 I want to solve this so so I will continue to consider this.

[mitchellh]

Coming back to this, I'd really like to solve this.

One suggestion above was to use wordexp(3). I'm not a fan of this for reasons well stated in this blog post: https://www.cipht.net/2023/11/21/worried-by-wordexp.html tl;dr it is extremely slow and complex, all major implementations shell out anyways, and it enables arbitrary program execution during expansion.

The original issue as stated was that the -e command is not correctly parsed. -e comes from a shell or manual exec call which by definition already gives us a nice array of strings. I agree in this scenario there is no reason to run this through /bin/sh.

Going further into implementation details, -e is implemented by being syntactic sugar over initial-command (and some other configs that are irrelevant for this issue and documented for that config).

I think that running a command through /bin/sh -c by default for command/initial-command in the config file results in the principle of least surprise. But for -e, the opposite is true.

Proposal

What I'd like to propose is some syntax for command/initial-command to NOT run it through /bin/sh -c. The syntax I'm thinking would be to prefix the command with !. i.e. command = ! /bin/whatever with args.

This syntax isn't obvious and you'd definitely have to read documentation to understand what's going on, but my expectation is that most users won't ever have to because both usage (in config file or -e) will apply the principle of least surprise.

For the config file ones, we will NOT do any shell expansion. We accept the args space-separated as-is. That means the following would NOT work: ! nvim "file with spaces" (you'd have to drop the !). But, since this is an opt-in, the user is shooting themselves in the foot. To be clear, this would work with -e because it has a different default, so the original issue would be resolved.

An alternative would be introducing a new config like command-uses-shell but I don't want to do this because we'd have to do it twice (for command and initial command), which is really bleh to me.

[mitchellh]

I think that the ! syntax (or anything else) is unnecessary unless we go all the way and support quoting and other escapes (or some other way of specifying arguments with spaces or other weirdness in them). Anything less I think is just going to generate bug reports.

I disagree with all three points here:

1. ! being unnecessary. Our CLI arguments have always mapped to file-based config. Everything you can do in the CLI you can do in the config and vice versa. The syntax is mostly there to support this as a non-magical behavior for -e. -e is the only real "exception" to the direct isomorphism but it still cleanly and deterministically maps to something you could do manually via a file.

2. "unless we go all the way and support ... escapes". This isn't necessary because ! is explicitly documented as NOT supported escapes/expansion. You'd just avoid the ! (the default) to get all that by running through a shell as we do today. Nothing changes for users.

3. This will generate bug reports. Its an opt-in behavior. Nothing changes by default for anyone except -e users (which you already support). If a user is explicitly using ! which is documented as "not supporting shell expansion" and also documented that you simply remove the ! to get shell expansion, well, that's an easy close. I doubt we'll see any increase in bugs here.

[mitchellh]

Maybe limiting "substitution" to some small subset (like "%h" for home, "%d" for the working directory being inherited by the window) instead of a full environment substitution.

No, I'm very against any form of this. My original post explains the motivation:

My goal with Ghostty's command and -e features are that they have straightforward, well-defined cases they work and don't work. I don't have a strong opinion where those edges are, except that maintainability is key.

Namely, I'd rather have a very clear boundary of what is and isn't supported than a vague scale.

I've implemented shell parsing at various points on the scale in a half dozen well adopted tools over the past 15 years and it was never once worth it. You always get users that need that "one more thing" ("it's only home expansion!") or you get a flurry of bug reports that things don't work like their shell does because its a subset. For most of those projects after a decade we reverted everything and went back to "dumb space splitting" which worked wonderful. The bugs disappeared. That's why I'm suggesting ! does dumb string splitting. I've done it before. It works fantastically.

Going all the way and subprocessing to /bin/sh or doing nothing at all are the only sane options. This is even bolstered by libc itself which subprocesses to /bin/sh to do expansion! (The only libc API that does so, I believe!)

EDIT: I think Gnome reimplements [a subset] of shell parsing for their "glib" library, and the implementation is almost 3000 lines of C code. And if you put a command expansion in there, it just subprocesses to /bin/sh anyways. I haven't looked at that in awhile, I only know about it because like 10 years ago I used it as a basis for my own implementation (that I ultimately threw away).

[c-wicklein]

I like where -e seems to be headed, but I don't follow the distinction between command = ... and command = ! .... With or without the !, I think the proposal still involves Ghostty executing what is specified with command.

I like the idea of using ! to signal an alternative mechanism for handling command and initial-command. This essentially matches how Terminal.app is configured on macOS. A command to run at start up can be specified, and its default mechanism of execution is changed by selecting a checkbox.

In patches relative to Ghostty 1.1.2, I've introduced alternatives to command and initial-command called send-command and initial-send-command, but I don't like this solution as much as using !. I was addressing my own problem without really understanding Ghostty's architecture or having any prior exposure to Zig. In my build, setting the configuration option send-command is essentially the same thing as setting the option command and checking the "Run inside shell" box.

Other than patching Config.zig to include the options send-command and initial-send-command, the only other change I make is to handle them in Surface.zig.

--- src/Surface.zig.orig        2025-02-13 17:03:54
+++ src/Surface.zig     2025-02-26 07:50:47
@@ -687,8 +687,30 @@
         }
     }

+    const send_command: ?[]const u8 = if (app.first)
+        config.@"initial-send-command" orelse config.@"send-command"
+    else
+        config.@"send-command";
+
     // We are no longer the first surface
     app.first = false;
+
+    const cmd = send_command orelse return;
+    if (cmd.len == 0) {
+        return;
+    }
+
+    var buf = try self.alloc.alloc(u8, cmd.len + 1);
+    defer self.alloc.free(buf);
+    for (cmd, 0..) |ch, i| {
+        buf[i] = ch;
+    }
+    buf[buf.len-1] = '\r';
+
+    self.io.queueMessage(try termio.Message.writeReq(
+        self.alloc,
+        buf,
+    ), .unlocked);
 }

 pub fn deinit(self: *Surface) void {

What I'd like to see from Ghostty so that I won't have to perpetuate my patches is:

1. -e works as with xterm. I think @mitchellh is leaning that way.
2. By default , command / initial-command continue to involve some variation on taking arguments to e.g. execv from the specified string. I'm not too concerned with exactly how that works.
3. Optionally, if the value assigned to command / initial-command begins with !, then that leading ! is stripped and the remainer of the string is "executed" by writing it to a login instance of the user's login shell, matching in effect the behavior my builds have with send-command / initial-send-command.

For me, writing commands to a login shell is a coup. The terminal program needs no special knowledge of how any particular shell parses commands, the specified command is parsed by the shell running it, i.e. correctly, and arguably, commands are executed in the least surprising way possible -- opening a new terminal with command set to some command has exactly the same effect as opening a new terminal window without having set command and me then typing some command into the terminal and pressing return.

[mitchellh]

Promoted to issue #7032