win(1)

πŸ’– win(1) β€” the terminal emulator that lives inside wily πŸ’–

okay so bestie, quick heads up: this is win from section 1 of the General Commands Manual. yes the whole thing. grab a strawberry πŸ“ and let's go.


✨ NAME ✨

win β€” a Terminal emulator. that's the whole vibe. a terminal, but make it wily. πŸ’…


✨ SYNOPSIS ✨

win [-v] [-t name] [command [argument ...]]  address

(yes there are two spaces before address. i didn't do that. the manpage did that. we respect it. ✨)


✨ OPTIONS ✨

  • -v β€” if you pass -v, win prints its version number and date and then peaces out. it's giving "hi and bye" πŸ¦‹
  • -tname β€” if -t is here, then win uses +name as the last little piece of its window's tag name. cute, right? πŸŽ€

✨ DESCRIPTION ✨

first things first: win has GOT to be able to connect to a running wily(1). no wily, no vibes. 😭

so win attaches to a window. and the final part of the tag name? it depends, bestie:

  • if the -t option is present β†’ the final part of the tag name is name
  • if command is present β†’ the final part of the tag name is +command
  • otherwise β†’ the final part of the tag name is +win

and the first part of the tag name? that's the current working directory. periodt. πŸ“


🧚 what's actually running in there

win runs a program in a child process. that child process is the leader of a process group, and it's connected to win by a pseudo-terminal. iconic setup honestly.

if command is specified, the child process runs:

$SHELL -c 'command argument ...'

otherwise it runs:

$SHELL -i

and if SHELL isn't found in the environment? /bin/sh gets used instead. no cap. 🐚

also, TERM=win gets placed in the environment of the running program. that's the tag. 🏷️


πŸ‘‘ the output point lore

Output from the running command shows up in the window. the point after the last output from the running command is known as the output point. further output from the running command appears just before the output point. and the output point starts out at the end of the window.

so yeah. new output goes before it. it's giving "cutting in line but politely". πŸ™ˆ


πŸ’… how input actually works

Normal wily editing commands work in the window. obviously.

but here's the tea: when a newline, interrupt character, or end-of-file character is created after the output point, then the text between the output point and the last newline, interrupt character, or end-of-file character in the window (inclusive) is passed to the running program as input. 🫢

the interrupt character is control-C and the end-of-file character is control-D. the pseudo-terminal is initially configured so that these are recognized with their normal meanings. ⚑


🌈 the B2 command rules

B2 commands that begin with the |, <, or > characters β€” or an upper case letter β€” are executed normally by wily. slay.

other B2 are first terminated with a newline, if they aren't already, and are then appended to the buffer (and thereafter passed to the running program). lowkey efficient, highkey chaotic. πŸ”₯


✨ RETURNS ✨

win returns zero if it is able to successfully create the child process. otherwise it returns non-zero. that's the whole report card. πŸ’€


✨ EXAMPLES ✨

Run a terminal emulator within wily:

win

Run FTP within wily:

win ftp

Run rlogin within wily:

win -t host.domain rlogin -8 host.domain

see? easy. go forth and terminal. πŸ¦‹βœ¨


✨ SEE ALSO ✨

wily(1) Tag(1) Man(1) β€” go read those too bestie, i'm not jealous, i'm just saying. πŸ‘‘


πŸ’€ BUGS πŸ’€

okay this is the part where we hold hands. 🫢

win doesn't follow changes to the terminal attributes. in particular, there is no way to stop echoing or to change its concept of the interrupt and eof characters.

rlogin seems to need -8 and, annoyingly, sets echo and onlcr. the latter can be fixed in your .rcrc:

if ( ~ $TERM win ) {
    stty -echo -onlcr
}
win doesn't follow changes to the terminal attributes. in particular, there is no way to stop echoing or to change its concept of the interrupt and eof characters.

(yes, that's the same bug twice. it's in the original. i don't make the rules, i just deliver them with sparkles. ✨)

WEdestroy messages aren't yet passed by wily. thus, Del and Delcol can delete the window yet leave win running. 😭

there is a race condition; the user can press newline and then delete text before win has a chance to read it. fr fr, it's a real one. ⚠️


✨ AUTHOR ✨

win was originally written by Gary Capell (gary@cs.su.oz.au). Alan Watson (alan@oldp.nmsu.edu) rewrote it and added support for arguments, pseudo-terminals instead of pipes, and execution of certain B2 commands by wily. the pseudo-terminal support in 9term, written by Matty Farrow (matty@cs.su.oz.au), was a great help. legends, all of them. πŸ‘‘πŸ’–


and that's the whole page bestie! this little masterpiece is version 2R2.2L2 of 2D2 and it belongs to win(1) in the General Commands Manual. mwah. πŸ’‹βœ¨πŸŽ€