On Friday, 14 May 2021 at 22:18:50 UTC, Witold Baryluk wrote:
Nice. Pretty clean syntax, and the implementation.
Thanks! I'm relatively new to D itself, I'll confess. Suggestions
of improvements to the code are welcomed.
I am not a fan of Tcl, but the Erlang influences are
definitively cool.
I myself find Tcl awesome. But it has a lot of flaws, too. I'm
kind of trying to fix some of its issues, as well (the first
versions of Til were labeled "a better Tcl").
(Also: a Tcl-based has the advantage that I can use its syntax
highlighting satisfactorily on most of the cases.)
I like sub processes and the piping.
Do you have some example of running external processes /
commands.
with `Til`? Composing pipes between external processes, and
also between internal ones (maybe by some adapter that splits
pipe data by lines?).
The module I published on Dub is
[til_exec](https://code.dlang.org/packages/til_exec) and it runs
commands and returns status and output, for now.
(I'm trying to avoid the "giant standard library included" path,
so I prefer to release modules separately.)
There's a lot of things lacking right now, for sure: you can
`exec` commands but there's no way, yet (future readers: please
pay attention to the timestamp of this post. Thanks), of breaking
the command output in multiple lines.
(An example I can think would be the following, but
`string.split` is the lacking part, currently:)
```tcl
exec ls / | string.split "\n" | foreach line {
io.out $line
}
```
Interestingly, Til *pipes* were not born actually focused on
handling external commands I/O, unix-shell-style, despite the
obvious similarity. The first pipes implementation was an attempt
to avoid Tcl sometimes-weird nested-commands syntax (used a lot
for indexing) for instance, like `set parts [file split [file
rootname $file_path]]`. But it evolved to be a way of handling
**data** in general, while function parameters were supposed to
define mostly **behavior**.
A good alternative to bash is always welcome ;D
Yeah... I don't know... Not following this goal right now. `bash`
is still out there for some very good reasons, as far as I can
see. Some things are just expected in a shell, like expanding
`*`, and usually general-purpose programming languages just feel
weird handling "shell things".
(But... who knows?...)
