I don't like "set [-l | -g | -U] [-x | -u]" naming.
It would be much more consistent if unexport was "-X", allowing "-u"
for universal:
"set [-l | -g | -u] [-x | -X]".
BTW, set's help should use the above format rather than "[SCOPE_OPTIONS]".
Or maybe "-X" for exported and "-x" for unexported.
Better yes, maybe we should make the scope/export cross product explicit:
"-l, -g, -u" for unexported vs. "-L, -G, -U" for exported? (Or vice versa.)
This makes 2. below less confusing.
Finally, changing the scope of an existing variable is confusing.
Frequently I set a variable but forget to export it, or later decide I
want it universal.
1. Doing "set -SCOPE var" resets var to an empty value!
This is probably not what the user intended when doing it on an
existing variable,
but I don't see a realiable way to know that.
- If the syntax was like "set x = y", "set -U x" would differ
from "set -U x ="...
- fish treats undefined vars almost like empty ones.
What if "set" never cleared existing variables without an explicit "-e"?
Alas, programatically doing "set x $y" must work even if $y is empty.
+ A warning about "set -SCOPE var" in interactive mode is the
best option I see now...
2. Changing just the scope or just the export status has tricky side effects:
- Dropping universality leaves a copy in each shell.
It might be better if it deleted it in all other shells.
+ "set -u var value" does work orthogonally to universality
- "set -e var" works on universal vars only from second attempt!
(Race condition?)
3. There is no easy way to query the scope of a variable!
One can check with "echo $x", "printenv x", then check from another shell...
Or one can do "set -n -x | grep -x z", "set -n -g | grep -x z" etc...
+ "set" listing should a format that can be executed back, in
particular including scope options:
set -Ux var 'first' 'second'
(And BTW, I think it should not shorten long variables (e.g.
$history) when output is not terminal. Better yet, there should be an
option.)
+ variable completion should show scope: "(Universal variable:
...)", not just "(Variable: ...)".
Part of the problem is that "set" tries to also be "get" which doesn't suit it.
But having many commands would be undiscoverable.
Maybe we should do the radical thing and call the command "var"?
Then it looks natural to do:
var # shows all (with scope and array quotes)
var x y # shows x, y (with scope and array quotes)
var -n # shows all (names only)
var -q x y # true if x and y exist
var -g # shows all globals
var -g x # makes x global, doesn't affect value
var -g x = a b # change value and make global
var x = a b # change value, doesn't affect scope
var x = # make value empty
var -d x # --delete x or --destroy x (IMHO better than "erase" which
might suggests "keep but make empty")
var x[(seq 2 4)] = b c d # slice assignment, unambiguous parsing
var first rest = $array # destructuring assignment, unambiguous parsing!
This is much better! I think we should introduce it, leaving "set"
existing though deprecated for the transion period.
Since writing "var x = 1" is long, maybe "set x 1" should be always
allowed. But the more complex options should be retired in favor of
"var".
(Should "var x=1" be allowed? "var x y=z w"? Probably yes but bad style.)
Or should take a hint from bash's approach and just allow "x = 1"?
(I know, Special Syntax Bad, but variables are really important -
otherwise we would get away with "(get x)" instead of "$x".)
But no, I can't see a way to parse it well. "=" is too frequent in
unix command lines.
Compromise: I suggest we allow typing it interactively (even "x=1"),
but on Enter we expand it to "var x = 1".
If we want, an explicit "=" syntax can also cleanly accomodate other
operators, like "+=" for appending (or arithmetic addition?)...
As a last tweak, "vared x" is lame.
It should be "var --edit x" (see my previous claim that "--erase"
should be "--delete").
And it should support editing arrays, and commit the resulting change
to history as a "var" command.
Both can be achieved by placing the command "var x = 'current' 'x'
'value'" at the command prompt.
And it would be neat if it was also accesible by typing "var x "<UP>,
even if you don't have it in history. (Pressing <UP> again should
then give access to such command in history, if any.)
--
Beni <[email protected]>
P.P.S. random note: "for x in ..." should highlight "in" in green,
"for x whatever" should hightlight "whatever" in red.
And "for x "<TAB> should comlpete "in ".
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
