Ok, I thought I understood shell launching with dash, but I do not understand yet. Will have to look at alacritty, contour, kitty terminal code more closely. On my macOS they all:

$ echo $0
-zsh

How’d that - prefix get there?

It looks like they insert it: • https://github.com/kovidgoyal/kitty/commit/8db838da9f50cf1fb6ef045eceb782b5e0964f4c#diff-d806b27d8e8a6f0464b502ebcdaf18cb4e65c4babd1666a2a4dd09697f26e924R78 • https://github.com/gnachman/iTerm2/blob/f6b54d66b5e371b9e69a0881e9608e13e710fda1/sources/shell_launcher.c#L42

I am probably getting confused with argv[0] is that I thought that was the first arg to the shell, but it is the shell itself? I should go study the code more.

yes, argv[0] is the program itself

the first arg is actually argv[1]

I think this comes from c

Right… my C is very rusty.

rust probably does it too, right?

My Rust is non-existent.

same

So can you invoke a shell in this way from the terminal?

Hmm… learning about exec… exec -l bash

I don't think so. I think it's when you use execvp or equivalent

yea

although, when you're already inside a terminal, I think most of the stuff that the login would provide is already setup

yeah, true, just trying to understand the mechanics…

I think it's more of an issue if you start the process outside of a terminal, for example: https://github.com/alacritty/alacritty/issues/645#issuecomment-313363581

So the leading dash is merely an indicator? If I exec an abitrary command like this, no harm?

depends on the arbitrary command, right?

Well, we are introducing :command so anything, the user specifies really. (I clearly don’t understand the mechanics of this dash prefix yet).

Nor how to express with pty4j yet, but can explore.

so interestingly, execvp allows you to specify argv separately from the executable path. many apis don't allow you to execute something with a different argv[0] since it's pretty rare

trying to see if pty4j allows this

so, it seems like it's possible, but it seems like the API we're currently using doesn't allow it. We might need to use a lower level API if we want to support this https://github.com/JetBrains/pty4j/blob/dd6ad8fdbae5c4c407ba165dd7f3c32dea68ecbc/src/com/pty4j/unix/UnixPtyProcess.java ie. don't use PtyProcessBuilder on Mac, https://github.com/JetBrains/pty4j/blob/dd6ad8fdbae5c4c407ba165dd7f3c32dea68ecbc/src/com/pty4j/PtyProcessBuilder.java#L132

An easier (for us) alternative would be to use -l or --login.

But this loses the leading - on the $0 which some folks might expect. (I assume that’s why the leading dash is preferred?)

as far as I can tell, it seems like they should theoretically do the same thing

I was suggesting that the leading - is preferred to avoid any incidental differences

I guess it's also a way to avoid trying to decide if we should or shouldn't append --login depending on the value of $SHELL if we do use that as a fallback default

Yeah, this way, the user controls the :command and we don’t tack anything on. On macOS we would default to <$SHELL val> --login else /bin/bash --login . But if those defaults do not work for the user, they can specify what they like via :command.

But other terminals seem to be doing the - prefix. So not conforming to that, is a negative.

so we currently call PtyProcess/exec , which is just a simple wrapper around https://github.com/JetBrains/pty4j/blob/dd6ad8fdbae5c4c407ba165dd7f3c32dea68ecbc/src/com/pty4j/unix/UnixPtyProcess.java#L283. On macOS, we could just call PtyHelpers/execPty directly.

Yeah… https://github.com/JetBrains/pty4j/blob/dd6ad8fdbae5c4c407ba165dd7f3c32dea68ecbc/src/com/pty4j/unix/PtyHelpers.java#L383? Probably worth exploring. But if the user specifies a non-shell thingy for :command do we still prefix with -? For example let’s say they want to run top , would it be harmful override argv[0] with -top?

I think that's why this hack exists. most programs don't actually care what it's in argv[0]

so it should be fine to prefix it for any command

I suppose if it does, by some odd chance, become a problem, we could address.

Without understanding nor appreciating the history (and perhaps cleverness?) of this dash prefix it seems rather icky to me.

I think it would also be ok to only prefix for default and default fallbacks

But if I want to run a different shell via :command ?

then you should be able to also supply the --login arg if that's what you want

here's the story I have in my head. for whatever reason, macOS decides all your terminal config should be in .bash_profile , which only is run as part of a login shell. this works mostly fine, but the user's shell is stored in the /etc/passwd db, which only supplies a single argument for the shell. the hack/workaround is this stupid - convention

Sure, that’s an alternative too. Maybe seems a bit odd that we can only support the dash prefix with the defaults.

sure, I don't have a strong opinion as to whether to prefix all commands with - or just the defaults

But introducing a :dash-prefix-command boolean option for macOS only seems a bit odd too maybe?

the case for not requiring it for defaults is that, presumably, the user that specifies commands knows the shell and its arguments whereas we don't actually know the shell and its args if we use $SHELL as a fallback

I wonder how many other folks working on terminals have had this same conversation? With a few expletives towards Apple in the mix.

the whole idea of emulating the vt100 decades later is kind of comical on its own 😛

Yeah! Very true!

not only do we emulate it, it's a critically piece of infrastructure to a large percentage of modern programming work!

I don't think :dash-prefix-command is necessary, but I'm not totally sure that it wouldn't be useful for someone. my usual approach would be to not include it, but create an issue that someone could comment or upvote if they have a use case for it.

however, I'm pretty open to whatever you think is best

How about… we start with… <flips coin>… adding the dash prefix to all argv[0]s (default or not) on macOS? I think I should summarize this convo in the issue tho. Will do that.