Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Rules" that terminal programs follow

jvns.ca

Post reply on HN
Print view View original

141–150 of 153 posts

Re: "Rules" that terminal programs follow

#141

Post by xg15 »

It's also important to know which rules are "hard", i.e. implemented or enforced by the first three (or implemented by the program, but would be a complete nonstarter to break) and which rules are just "conventions", like the "short options/long options" rules in POSIX.

In particular, those can change between OSes: On all linuxes, programs already get a pre-parsed array of command line args on start, so parsing and quoting behavior depend on the shell, not individual programs.

On Windows, programs get passed the entire command line invocation as a string and have to do the parsing themselves. While all "well-behaved" programs let the libc do this, it's perfectly possible for a program to break the rules here.

Re: "Rules" that terminal programs follow

#142

Post by Sharlin »

jasomill wrote: post #137
Sharlin wrote: post #94

Earlier quoted context omitted.

That's a good point, particularly given that .. is handled for you at the OS API level so you might be inclined to expect ~ is too on POSIX.

This would massively complicate kernel path resolution on many systems. Taking Linux as an example, even in the simplest cases, ~user expansion as typically implemented — via the getpwnam(3) libc function, which in itself implies a rather unfortunate dependency — requires reading and parsing /etc/passwd, and may also require access to network directory services like LDAP.

Sure, I don’t mean it should be that way, just that there might be a tacit assumption.

Re: "Rules" that terminal programs follow

#143

Post by anthk »

saghm wrote: post #87
Sesse__ wrote: post #28

Earlier quoted context omitted.

If you ever need to do so again, try gqlplus, which wraps sqlplus to add such quality-of-life features :-)

I hope my streak of almost a decade of not needing to use Oracle will continue, but if not, I definitely will be looking for alternatives to sqlplus...

Use rlwrap with your tool as an argument:

rlwrap tclsh

rlwrap foo

rlwrap bar

And so on.

Re: "Rules" that terminal programs follow

#144

Post by trealira »

Calzifer wrote: post #103
jrockway wrote: post #67

One that's missing is treating ~ as the home directory. This appears to be a shell thing and not a POSIX API thing. For example, this doesn't work: func main() { if _, err := os.ReadFile("~/.bashrc"); err != nil { log.Fatal(err) } fmt.Println("ok") } Meanwhile over in shell land: $ echo ~/~/~ /home/jrockway/~/~ The behavior is actually kind of amazing. I mention it because while "yourprogram ~/path/to/file" always wo…

In my opinion it should remain a shell thing. Adding tilde expansion just complicates the implementation of the tool. Now you need to know the current users home directory. And some tools might implement it incomplete so that '~' works but '~name' does not work. In POSIX shells '~name' expands to the home directory of user 'name' $ echo ~bin /bin Now your tool need a way to query home directory for any user including…

I remember reading some rant about how Unix sucks because of the shell's filename expansion, because programs can't tell whether you wrote a star or actually just all the files in the directory. If programs could tell the difference, then you could get the desired renaming behavior from mv like this:

  mv *.m *.c
They suggested that this filename expansion should be in the C standard library, not the shell.

Going further, as part of shell expansion, expanding the tilde could also be useful for filename expansion in the standard library.

Re: "Rules" that terminal programs follow

#145

Post by [deleted] »

Vegenoid wrote: post #135
neilv wrote: post #117

Earlier quoted context omitted.

The default configurations of most terminals includes illegible color combinations. So I think it's not on every user to somehow design optimal color palette settings on their computer that work in all combinations (if they even can), but rather on the developers of software not to say "Hey, I bet every yellow would be legible on white" or "Yolo, I bet yellow is legible on every background, so I'm just going to set t…

> The default configurations of most terminals includes illegible color combinations This hasn’t been my experience - while I’m not familiar with a wide breadth of terminal emulators, all the ones I’ve used have a default black background with the ANSI colors being very bright, making them clearly visible. I would again say that if a terminal emulator has some of the standard ANSI colors set to not be visible on thei…

[deleted]

Re: "Rules" that terminal programs follow

#146

Post by Cpoll »

Terr_ wrote: post #91
neilv wrote: post #42

Additional suggestions: * Respect the user's default foreground and background color. Don't change them without good reason. * If you use colors, make them legible regardless of what the default background and foreground colors are, and regardless of the terminal's color map. * Don't use color as the only indication of something. The user's terminal might not display it, and it probably won't be preserved in copy&pas…

> Use emoji only judiciously, if at all. That reminds me of an incredibly annoying bug I encountered a few years ago involving Docker. One of the scripts being run was outputting emoji to STDOUT, and this was causing the interactive terminal to crash and thus the container to exit. (This issue [0] has error-strings and simple repro tests.) I'm not sure if the root cause ever got fixed, but I (and many others) ended u…

Nit: ┐ isn't emoji. It's a box drawing character, and they've been around in one form or another since at least the 80s. The modern form has been part of Unicode from (nearly?) the beginning.

In any case, the character itself is unrelated to the bug. As someone pointed out in the bug thread, certain Cyrillic strings will also cause it.

Re: "Rules" that terminal programs follow

#147

Post by mmphosis »

neilv wrote: post #112
ratorx wrote: post #108

Earlier quoted context omitted.

You can delegate the choice to the terminal by using ANSI color codes [1]. Then the onus is on the user/terminal developer to make sure the colors they’ve configured (or the defaults provided) are reasonable. A downside of this is that it is quite restrictive, there are only like 8 colors. EDIT: I missed the “regardless of the color map” bit, that is a bit unreasonable. Either you trust the terminal emulator or don’t…

For example, I've seen a program that sets foreground color to a symbolic (not RGB value) yellow, and doesn't set background. While that combination might be legible on some terminals, it's definitely not on all of them. Don't assume that the user's terminal's color map makes all combinations legible.

  printf '\e[48;5;196m\e[93m test \e[!p\n'

Re: "Rules" that terminal programs follow

#148

Post by aaravchen »

_kst_ wrote: post #129
eschaton wrote: post #124

Other rules for command line tools: 1. Don’t assume a terminal type. Look at `TERM` and use termcap/terminfo or a library built atop them for anything beyond line-oriented plain text output, or least assume a plain teletype unless you specifically recognize the user’s terminal type. 2. Don’t assume the presence of a terminal at all. Check `isatty()` before doing anything fancy, and be sure to work without a terminal…

> 1. Don’t assume a terminal type. Look at `TERM` and use termcap/terminfo or a library built atop them for anything beyond line-oriented plain text output, or least assume a plain teletype unless you specifically recognize the user’s terminal type. I agree, but these days I think you can mostly get away with assuming VT100-compatible behavior. > 4. Use the standard ` ` exit codes. They exist for a reason and they ma…

In most practices I've seen, >=128 is reserved because it uses a special bit flag, and fixed codes 64-127 are reserved. But <64 is treated as a free-for-all. Most people are only using existing code 1, but if you have a reason to return specific different exit codes you need more than a couple.

Re: "Rules" that terminal programs follow

#149

Post by aaravchen »

eschaton wrote: post #124

Other rules for command line tools: 1. Don’t assume a terminal type. Look at `TERM` and use termcap/terminfo or a library built atop them for anything beyond line-oriented plain text output, or least assume a plain teletype unless you specifically recognize the user’s terminal type. 2. Don’t assume the presence of a terminal at all. Check `isatty()` before doing anything fancy, and be sure to work without a terminal…

I've never heard of the `@/path/to/file` convention, nor ever seen anything that documented using or supporting it. Do you have any examples of tools that do use it (maybe I've just never seen it in the documentation)?
Post reply on HN