Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider providing easy way to override argv[0] #112

Open
lread opened this issue Dec 11, 2021 · 2 comments
Open

Consider providing easy way to override argv[0] #112

lread opened this issue Dec 11, 2021 · 2 comments

Comments

@lread
Copy link

lread commented Dec 11, 2021

Thanks

First, and foremost, thanks for pty4j, it is a very useful lib!

Disclaimer

My understanding is just that and could be wrong.
I am happy to learn if/where I've gone astray.

Use Case

I am contributing to an experimental open-source terminal that uses pty4j.

On macOS, due to the way Apple implemented shell initialization, it seems it is best practice to launch the shell for a terminal as a login shell.
This can be done via:

  1. specifying an -l or --login option to bash
  2. overriding argv[0] with a - prefix. For example, launching /bin/bash results in overriding argv[0] from /bin/bash to -bash.

We looked at kitty, alacritty, iTerm2 and contour. They all picked option 2.
So we'd like to do the same.

Issue

While I do see pty4j has an exec method in com.pty4j.unix.PtyHelpers that looks like it would allow me to override argv[0] via its argv parameter, using it directly seems to mean I would lose the benefits of com.pty4j.unix.UnixPtyProcess.

Proposal

Make it easier to override argv[0].

Here are some initial ideas:

  1. For me, ideally, this would be via a new option in one/more of the exec methods in com.pty4j.PtyProcess. Perhaps something named argv0Override? I don't think this is valid for Windows, so on that OS, if specified, it could be ignored (or throw, whatever makes sense).
  2. Another alternative that might be workable is making exec in com/pty4j.unix.UnixPtyProcess public and override-able. This, I think, would allow me to replace exec behaviour to do my argv[0] override bidding.
  3. ?? Does anyone else see another good option I am missing?

Next steps

If this makes sense and is of interest, I could take a crack at a PR after we agree on an approach.

@segrey
Copy link
Collaborator

segrey commented Dec 27, 2021

@lread Sorry for the delay. Thanks, as I can see, kitty adds - prefix. Are there any benefits of prepending shell name with - over passing --login?

Have you tried to prepend shell name with a dash and pass it to com.pty4j.PtyProcessBuilder#setCommand?

@lread
Copy link
Author

lread commented Jan 3, 2022

@lread Sorry for the delay.

No prob! Sorry for my slow response to your delayed response. 🙂

Thanks, as I can see, kitty adds - prefix. Are there any benefits of prepending shell name with - over passing --login?

I don't really know enough to answer that, but it seems like most terminal implementations opt to use the - pretending trick, so I figured we should follow suit.

Perhaps this technique is more generic/transparent across more shells?

Have you tried to prepend shell name with a dash and pass it to com.pty4j.PtyProcessBuilder#setCommand?

No, I thought that would not work because we eventually get to this invocation:

return PtyHelpers.execPty(cmd[0], cmd, envp, dirname, slaveName, masterFD, errSlaveName, errMasterFD, console)

which I think would try to invoke a cmd[0] with the dash prefix which would fail.

My 2nd proposal was a clever (?) idea to allow me to override just a wee portion (the exec method) of UnixPtyProcess to maybe (?) get the desired effect. If this seems viable and interesting, I could explore more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants