- https://tebibyte.media/~emma
-
fae/faer
- Joined on
2022-02-27 -
-
qi(1): Syntax
The rest of the comments in #8 are the discussion of a system of variable expansion that does not distinguish between plaintext and variable names. This syntax has been verbally discussed by…
qi(1): Syntax
alright i haven't slept in a few days and have important things to be doing rn, what better idea than to propose shell syntax. this is poorly thought-out and full of holes. have fun deciphering…
qi(1): Syntax
Alright, this is the continuation of my last comment.
The behavior of the traditional POSIX shell with regards to unquoted variable expansion is useful, sometimes, but usually unwanted and a…
qi(1): Syntax
I have further thoughts on shell quoting.
When I think of program execution I think of the exec function family in C's <unistd.h>:…
qi(1): Syntax
The way POSIX shell does variable assignment is awful.
#!/bin/env -i /bin/sh # ^^ don't inherit an existing environment echo "$x" # unassigned (vars are "" by default),…
qi(1): Syntax
The way POSIX shell does variable assignment is awful.
#!/bin/env -i /bin/sh
# ^^ don't inherit an existing environment
echo "$x" # unassigned (vars are "" by default), so it'll echo…qi(1): Syntax
Plan 9's rc(1) doubles quote runes to escape them:
; echo "foo"
foo
; echo ""foo""
"foo"
; echo ''foo''
'foo'
Which I've always felt is quite nice.
The reason sh(1p)'s…
qi(1): Syntax
I've been asked to submit my grumblings about POSIX shell quoting to this issue. I am lacking sufficient energy to write eloquently (or at all) about this so here's an example.
#…qi(1): Builtins
Its definition in POSIX makes it unintuitive for shell scripters. Emma should elaborate here when fae has time, fae has more experience with this.
From: "Lawrence Velázquez" <vq@larryv.m…qi(1): Builtins
It necessitates storing "$0" as a new shell variable to be able to continue using it, which shell authors writing diagnostics messages and following good practice always want to do.
shift(1)…
qi(1): The qi shell
I’m going to work on getting this issue split out into a few others to make it easier to work with.
kv(1) - key/value
Configuring things via environment variables is generally very clumsy. Changing a configuration value requires setting the variable(s) in your profile, and logging out and back in again
This…
kv(1) - key/value
I see where I misunderstood. The kv(1) command i in your original proposal returns the variable value from the store. Altogether, though, I’m starting to wonder what the benefit of this is…
kv(1) - key/value
This would be more idiomatic:
$ config=~/.config/greeter.conf $ mm -i "$config" timeOfDay=morning name="$USER" $ mm -i "$config"
kv(1) - key/value
Setting values in the file could be achieved through manual editing and in scripts by existing (or not yet existing) tools.