Thanks, the readme has been expanded now so that it has better examples, and the full documentation (https://github.com/tomhrr/cosh/blob/main/doc/all.md) is more clearly marked for those who are looking for more detail.
45 karma · joined December 21, 2022
Thanks, the readme has been expanded now so that it has better examples, and the full documentation (https://github.com/tomhrr/cosh/blob/main/doc/all.md) is more clearly marked for those who are looking for more detail.
There is definitely a 'write-only' angle to concatenative (postfix) languages that rely on a stack. I think this type of language/approach is uniquely well-suited to this use case, though, where the focus is interactive use, plus short programs that are not generally intended for distribution, since you get the most out of the advantages around conciseness, without incurring the costs that come with larger programs.
1 2 +; 3 *
(The semicolon is used to indicate that the previous string (token) is a function and should be executed. In some instances this is implicit, like when the last string (token) in a larger command (like the one above) maps to a function name, in which case it will be treated as a function call even when no semicolon appears after it.)I'm not sure I'd characterise these parts of the Unix philosophy as 'wrong'. For example, if you are writing a shell program for use by somebody else, then having that program work with text streams makes sense. The focus here is interactive use and short functions/programs for local use, though, which means that the text stream part of the philosophy becomes a less pressing consideration.
> I would welcome a discussion of how the Unix philosophies break down, or what they prevent. But I didn’t find that here.
At least as far as text streams go, the readme talks about awkward considerations like '-0' and '-print0', but more generally, when the command doesn't output a known format like XML or JSON, parsing the output can be fun (e.g. per https://stackoverflow.com/a/15643939). Oftentimes the response is "the command has flags for getting the data that you want", but it's simpler (IMHO) not to build this sort of functionality into every command, and instead just have the shell support it more nicely, whether by providing a function that produces a first-class value (e.g. 'ls', 'ps' here) or by providing more generic parsing functions (e.g. 'split', 'splitr' here).
Thanks, I'll look at adding some simpler examples.
> I would have to look up `-0`
The thing about '-0' is that it's not required in cosh, because you're dealing with proper values instead of text streams. The problem that '-0' (and '-print0') is addressing doesn't arise.
> Why does cosh use ; the syntax kinda looks like they're not needed?
';' needs to be used to denote the previous string (token) as a function where that can't be determined from context. For example, if you type '1 2 +' and press enter, the shell will assume that because there's a function called '+', the intention is to run that function, but you could also enter '1 2 +;' (or '1 2 + ;') to get the same result. Whereas '1 2 + 1 2 + +' doesn't work, because the shell doesn't know if the first two '+' symbols are meant to be interpreted as function calls or just plain strings. The other place where it assumes that a function call is intended is at the end of an anonymous function, so `[1 2 +]` and [1 2 +;]` have the same effect.
find . -iname '*test*' -print0 | xargs -0 grep data
but possibly a bad assumption on my part that the mapping was clear. In any event, 'm' is for regex string matching, and 'f<' is for reading a file into a generator (basically an iterator over the lines in the file). It's a good point that more, simpler examples would help.- https://github.com/wee-slack/wee-slack with WeeChat (weechat.org) for IM only (i.e. configured so that it only notifies when an IM (one-on-one or group) is received); and
- https://github.com/tomhrr/paws for retrieving messages from Slack as email, and sending responses to those emails to Slack.
https://github.com/nicm/fdm is used for all filtering of email, including Slack messages. This allows for rules like e.g. marking everything from Slack as read, unless it's from channel X and matches your username, or it was sent after 6pm, or similar.
With this setup, IMs still come through as IMs, but everything else goes to email and is treated like email. Retrieving email and Slack messages happens based on local configuration, so it can e.g. be set up to fetch once per hour, and then all of those messages can be dealt with in one go. As the filters are refined, the number of useless messages that have to be reviewed decreases. With this configuration, at least in my experience, Slack is much less of a nuisance.