Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* ape loader: $prog.ape + login shell support If the ape loader is invoked with `$0 = $prog.ape`, then it searches for a `$prog` in the same directory as it and loads that. In particular, the loader searches the `PATH` for an executable named `$prog.ape`, then for an executable named `$prog` in the same directory. If the former but not the latter is found, the search terminates with an error. It also handles the special case of getting started as `-$SHELL`, which getty uses to indicate that the shell is a login shell. The path is not searched in this case, and the program location is read straight out of the `SHELL` variable. It is now possible to have `/usr/local/bin/zsh.ape` act as a login shell for a `/usr/local/bin/zsh` αpε, insofar as the program will get started with the 'correct' args. Unfortunately, many things break if `$0` is not the actual full path of the executable being run; for example, backspace does not update the display properly. To work around the brokenness introduced by not having `$0` be the full path of the binary, we cut the leading `-` out of `argv[0]` if present. This gets the loader's behavior with `$prog.ape` up to par, but doesn't tell login shells that they are login shells. So we introduce a hack to accomplish that: if ape is run as `-$prog.ape` and the shell is `$prog`, the binary that is loaded has a `-l` flag put into its first argument. As of this commit, αpε binaries can be used as login shells on OSX. * if islogin, execfn = shell Prior to this, execfn was not being properly set for login shells that did not receive `$_`, which was the case for iTerm2 on Mac. There were no observable consequences of this, but fixing it seems good anyway. * Fix auxv location calculation In the non-login-shell case, it was leaving a word of uninitialized memory at `envp[i] + 1`. This reuses the previous calculation based on `envp`.
- Loading branch information