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

Merge system utilities list in README? #4422

Closed
mqudsi opened this Issue Sep 21, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@mqudsi
Copy link
Contributor

mqudsi commented Sep 21, 2017

Currently, README has two separate lists of fish dependencies on "system utilities" (not including optional features):

  • basic system utilities including basename, cat, cut, date, dircolors, dirname, ls,
    mkdir, mkfifo, mktemp, rm, seq, sort, stat, stty, tail, tr, tty, uname,
    uniq, wc, and whoami
  • a number of common UNIX utilities:
    • awk
    • find
    • grep
    • hostname
    • kill
    • ps
    • sed

What's the distinction between a "basic system utility" and a "common UNIX utility"? In the latter list, all are POSIX utilities except hostname and in the first list, all but dircolors, mktemp, seq, and stat are standard POSIX utilities.

Either the two lists should be merged or replaced with a list of POSIX and a list of non-POSIX but fairly common utilities (even better would be to drop the dependencies on non-posix utilities for posterity's sake).

@faho

This comment has been minimized.

Copy link
Member

faho commented Sep 21, 2017

What's the distinction between a "basic system utility" and a "common UNIX utility"?

The former are all in GNU coreutils. I'm not sure if that particular distinction is worth it, but a "you probably have these" section might be.

So:

replaced with a list of POSIX and a list of non-POSIX but fairly common utilities

👍.


even better would be to drop the dependencies on non-posix utilities for posterity's sake

We can remove dircolors from that as it is strictly optional. stat is only used in the screen completions and __fish_print_packages (in that case only on coreutils-using linux distributions), though I don't see an alternative. For seq we have a fallback function, but that's dog-slow IIRC.

hostname should be more optional than it is. We mainly use it in prompts and we have converted all of them to use prompt_hostname, so we could let that print nothing if it doesn't exist (or use alternatives like we already do on Cygwin). The one other use I can find is the terminal-$PWD-notification stuff (in __fish_config_interactive), but I don't see an alternative for that - IIUC, that requires us to print the hostname, so we need a way to find it.

mktemp is gonna be an issue - we use it in psub, so it's pretty important, and there's not a great replacement.

@mqudsi

This comment has been minimized.

Copy link
Contributor

mqudsi commented Sep 21, 2017

Thanks for that info, it would have taken me forever to dig that up.

It's odd that hostname is not a standard utility. The gethostname() function is part of POSIX.1, so I'm not sure if there's any POSIX OS that doesn't have the hostname utility in practice. It feels like a waste to write a builtin that just calls gethostname()...

IMHO, seq is popular enough and readily available enough that even if the fallback is insanely slow, so long as it exists we can drop seq from the list?

@krader1961

This comment has been minimized.

Copy link
Contributor

krader1961 commented Sep 21, 2017

Also, now that we have argparse and math is a builtin there isn't any reason our seq function can't be within a factor of two or three of the external seq command. It might even be worthwhile to rename __fish_fallback_seq to fseq and make it always available so that people don't have to worry about the differences between BSD and GNU seq. For example, the two versions handle seq 10 0 differently. Then simply have seq wrap fseq if there is no external seq command. In any event it would be nice if someone rewrote __fish_fallback_seq so it wasn't so hideously expensive and behaved more like the external command it's meant to mimic.

@faho

This comment has been minimized.

Copy link
Member

faho commented Sep 21, 2017

the differences between BSD and GNU seq

Urgh, I completely forgot about that! I had actually written a builtin implementation of seq before, possibly also motivated by that tiny little annoyance.

It's odd that hostname is not a standard utility. The gethostname() function is part of POSIX.1, so I'm not sure if there's any POSIX OS that doesn't have the hostname utility in practice. It feels like a waste to write a builtin that just calls gethostname()...

Note that:

  • We have had issues regarding hostname before - mostly it being sometimes slow (specifically hostname -s) and the rpm dependencies being annoying.

  • We currently call gethostname() for the uvar file (which #1912) wants to abolish. So it seems plenty fast in all cases (or we should have gotten an issue).

  • A potential $HOSTNAME variable has been discussed before (in #202 and #3479) - and that's the way I'd go about this, since there's no reason for us to provide anything more complicated.

@krader1961

This comment has been minimized.

Copy link
Contributor

krader1961 commented Sep 21, 2017

A potential $HOSTNAME variable...

Heretic! I've been told that all uppercase var names are evil and offend the fish god Poseidon 😸

@faho

This comment has been minimized.

Copy link
Member

faho commented Sep 22, 2017

Okay, a hostname variable, name TBD.

@krader1961

This comment has been minimized.

Copy link
Contributor

krader1961 commented Sep 23, 2017

A potential $HOSTNAME variable...

This also begs the question of whether the value of that variable should ever change after the shell has started. AFAICT the bash shell sets the var once and ignores any subsequent changes to the host name (see issue #3479). The reason I'm mentioning this is that an explicit invocation of the hostname command means that changes to the host name after fish has started running will be recognized and reflected in things like the prompt. Whereas if we provide a $HOSTNAME (or $hostname) variable the result is not the same. Specifically, if a singleton whose value is frozen when the fish shell starts then subsequent DNS changes won't be reflected in that var. However, if we make it an "electric" variable whose value is calculated every time it is referenced then there isn't much point in providing a variable rather than just having the user run the hostname command.

I'm making this comment to point out that such decisions are non-trivial. Whether or not fish caches the value of gethostname() or any related function needs careful consideration since it is best if the behavior doesn't change in the future. We need to also consider whether looking up the hostname should be done in a separate thread. Plus a very short (e.g., no more than 100 ms) timeout imposed on attempts to wait for that thread to complete. If we don't then we're still faced with DNS (or other host name resolution mechanisms like NIS/Yellow Pages) problems causing annoying delays even if only once the first time the variable is used. Also, if we allow that thread to continue running after the first attempt to use the var times out then the user might see unpredictable, hard to explain, behavior. Consider that the first use of the var might return an empty string (or other magic value indicating we couldn't determine the host name) while a subsequent use might return the expected host name.

Lastly, should the value be the FQDN or just the host name? Note that bash provides the FQDN and uses all uppercase for the var name. But bash does not export that var. Which, despite my earlier, tongue in cheek, comment I think we should mimic. Also, note that csh (beloved by the person bothered by all uppercase var names that are not exported) uses $HOST for this purpose and does export the var. Csh also ignores any existing HOST env var when it starts running and replaces its value with the one it calculates. Behavior that is questionable.

mqudsi added a commit that referenced this issue Mar 9, 2018

Merge branch 'hostname'
This addresses the discussion regarding the dependency on `hostname` and
the addition of a `$hostname` variable to replace it.

`$hostname` is a read-only, GLOBAL_ENV, non-electrified, lowercased,
non-exported variable that is read once at the start of a fish session.
The finer points of this can be debated endlessly, but this is a shared
starting point that any changes can build on (ref #4422).

Regarding performance: @krader1961 brought up some good points in #4422
regarding potential DNS timeouts (but they really don't apply except if
the host name is not hardcoded in resolv.conf, which quickly manifests
with a cascade of errors on most *nix systems in all cases), but note
that gethostname() was already being called by fish so that would be
more of a future optimization than a "must" at this point.

@mqudsi mqudsi closed this in b575e12 Mar 9, 2018

@faho faho added the cleanup label Sep 26, 2018

@faho faho added this to the fish-3.0 milestone Sep 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment