There seems to be some trouble with gmail and
sourceforge. Specifically all mails I've sent the last
few days have gone to the bitbucket. I'm resending
them from this temporary address. Hope the forwarding
doesn't mess up the formating completely.
Hi all!
I'm back from my vacation. Glad to see there have been
some
interesting discussions on the list while I'm gone, as
this will make
catching up on my email more interesting.
On 9/22/06, Beni Cherniavsky <[EMAIL PROTECTED]>
wrote:
> Universal variables gave me a crazy idea. I don't
know yet what to do
> about it, so I decided to toss it here rather than
think alone.
>
> Builtins and functions are evil from the user's
perspective, because
> they are invisible to other programs. E.g. last
week I tried ``env
> BROWSER=links help ...`` which of course didn't work
because `help` is
> a function. Which means that `env` can't fully
replace the requested
> set-for-one-command feature.
>
> Why do we have builtins at all?
> (1) Things like ``set`` are builtin because a
subprocess can't modify
> the shell's state.
> (2) Things like ``while ... end`` are builtins to
have special syntax
> recognized by the parser.
> Functions are essentially builtin scripts, existing
for reason (1).
True. Though I would also add that some functions are
not external
commands because that would only clutter the
namespace. 'help' is only
every useful when using fish, so I made it a function.
I did not
realise that you might want to run it through 'env'.
>
> But (1) is not a reason, as fishd proves: if the
shell becomes a
> server, things like ``set`` and ``cd`` can be
implemented as external
> commands!
With a bit of trickery, they could. That is true, and
pretty cool,
actually. Nice one.
> This is perhaps an immediately good idea.
Implementation-wise, you'd need to update fish a bit
to do that.
Specifically, you can't currently change the value of
a universal
variable in only one shell. You'd need to be able to
do something like
'set --universal --on-process [PARENT PID] CWD /usr'.
Adding this
makes sense to me. If one was to make 'set' an
external command as
well, one would need to go even further, and allow the
user to set
local and global variables through fishd, which has
some rather nasty
implications for security and code obfuscation
potential.
For 'cd' I think this may be a good idea, I think the
drawbacks for
'set' are large enough that this is a bad idea.
>
> As for (2), it is possible to turn control
structures into external
> commands, but it requires going a long way toward
TCL. Consider
> `xargs`: it's essentially a for loop (at least in -1
mode). And
> `watch` is a ``while true`` loop with some output
wrapping. The trick
> is to supply the body as an argument, quite like in
TCL. It means you
> need to quote multiple, perhaps nested commands in
some way. More
> importantly, it means parsing of command boudaries
can't depend on the
> command being used (because it's external). Both
lead almost
> inevitably to TCL-style quoting with symentric
delimiters, e.g.
> ``while COMMAND [CMD; CMD]`` instead of ``while
COMMAND; CMD; CMD;
> end``.
> I have a growing feeling that TCL got this aspect
right but it's
> obviously a very major change.
The first few fish versions worked like that. You
wrote a for-loop like this:
for i in *.c 'echo $i'
I think this is bad, for several reasons. Most reasons
boil down to a
decreased before-hand knowledge of the code, since you
don't know what
a specific command does. This makes it extremely hard
to do dependable
ahead-of-time syntax analysis in order to point out
possible problems,
something which fish is currently very good at (For a
shell). Syntax
highlighting also becomes less dependable.
The upside of a TCL-like syntax from a
feature-perspective is mostly
that you can implement your own language constructs,
for example you
can write a spiffy new kind of for-loop. I would argue
that this is
actually a bad idea, since if you can redefine the
language on the
run, then most people will effectively be writing
stuff in their own,
private language. No copy-and-paste of code, no
learning how to code
by looking at other peoples code, etc., etc.. You may
say that I
exaggerate, but if you look at the example of TCL,
they actually have
several semi-common object oriented language
extensions, and these are
mostly incompatible, so they have exactly this
problem. And to be
quite honest, I have yet to see a single TCL program
that was made
shorter and more readable by TCLs ability to redefine
'for'.
Lastly, _if_ you really do need to implement a spiffy
new for-loop in
fish, you can do that. You can't call it for, since
that name is
reserved, and it will have to use a more TCL-styled
syntax instead of
the blocks used by regular 'for':
function for2
set var $argv[1]
set -e argv[1]
set count (count $argv)
set body $argv[$count]
set -e $argv[$count]
for i in $argv;
set $var $i
eval $body
end
end
for2 i *.c 'echo $i'
In the end, it would be really nice if more builtins
could be made
into external commands, looking over the list of
builtins, 'cd',
'functions', 'bind', 'commandline' and a few more seem
like possible
candidates. But personally, I think that the drawbacks
are larger than
the advantages for block commands, set and a few more.
>
> --
- Show quoted text -
> Beni Cherniavsky <[EMAIL PROTECTED]>, who can only
read email on weekends.
--
Axel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
