Fork me on GitHub
#membrane-term
<
2021-12-07
lread21:12:30

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

lread21:12:53

How’d that - prefix get there?

lread21:12:44

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.

phronmophobic21:12:28

yes, argv[0] is the program itself

phronmophobic21:12:42

the first arg is actually argv[1]

phronmophobic21:12:46

I think this comes from c

lread21:12:57

Right… my C is very rusty.

phronmophobic21:12:11

rust probably does it too, right?

lread21:12:37

My Rust is non-existent.

simple_smile 2
lread21:12:29

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

lread21:12:07

Hmm… learning about execexec -l bash

phronmophobic21:12:10

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

phronmophobic21:12:02

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

lread21:12:41

yeah, true, just trying to understand the mechanics…

phronmophobic21:12:36

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

lread21:12:11

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

phronmophobic21:12:33

depends on the arbitrary command, right?

lread21:12:23

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

lread21:12:58

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

phronmophobic21:12:31

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

phronmophobic21:12:44

trying to see if pty4j allows this

phronmophobic22:12:31

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

lread22:12:19

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

lread22:12:59

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

phronmophobic22:12:51

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

phronmophobic22:12:40

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

phronmophobic22:12:55

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

lread22:12:19

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.

lread22:12:03

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

phronmophobic22:12:36

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.

lread22:12:27

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?

👍 1
phronmophobic22:12:45

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

phronmophobic22:12:03

so it should be fine to prefix it for any command

lread22:12:24

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

lread22:12:18

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

phronmophobic22:12:37

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

lread22:12:44

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

phronmophobic22:12:09

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

phronmophobic22:12:30

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

lread22:12:37

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

phronmophobic22:12:55

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

lread22:12:15

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

phronmophobic22:12:51

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

lread22:12:34

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

1
phronmophobic22:12:06

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

lread22:12:30

Yeah! Very true!

phronmophobic22:12:56

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

phronmophobic22:12:36

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.

phronmophobic22:12:02

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

lread22:12:30

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.

🎉 1
👍 1