Unix Shell - Announcing the friendly interactive shell

Author

Announcing the friendly interactive shell

Axel Liljencrantz

2005-02-15, 8:06 am

I've long been irked by how much shells like bash and zsh seem to
focus on scriptability, when I spend 90 % of my time in front of a
shell using it interactively.

Among the features I've missed in modern shells are:

* Good terminal handling, like detecting when a background process has
written output and automatically redraw the prompt, using terminfo to
make sure backspace and delete will work more often, writing process
exit notifications as soon as a process exits, etc, etc.

* Discoverability. After using UNIX for 10 years, I still find out new
features of Bash. I friendlier help system, preferably easy to find
help in HTML format.

* Better tab completion. I hate the fact that I can't use tab
completion on file arguments containing wildcards. I love programable
completions, but few people use them, since they're not enabled by
default.

* When displaying a list of possible completions, wouln't it be nice
with a description of each completion, like 'Character device' or
'Manual page'? This is even more useful when combined with the
programable completions of options. Cant remember the option to set
the ssh encryption algorithm? Type 'ssh -' and double tap on tab, and
a nice list of all ssh options, with short descriptions appear.

* A useable pager for displaying long lists of tab completions. zsh
jus prints all the completions, even if they won't fit. Bash uses a
really bad pager. The pager should be able to scroll up and down both
lines and pages at a time, and it the user starts typing, the pager
should exit without consuming the output.

* Syntax highligting. Pretty colors by themselves don't add very much,
but combined with a bit of error detection, this is useful. Errors
like reading from a non existant file, issuing a non-existant command
should be highlighted.

* A syntax that doesn't suck. OK, so a shell for scripting should
probably be POSIX compliant, but a interactive shell should focus on
beeing actually useable. This is 2005, and writing 'foo = bar' doesn't
work? And how intuitive is it that an environment variable with spaces
is separated into multiple arguments unless it is quoted? Single
quotes and double quotes are used for two different kinds of quoting
while backticks, which look nearly identical to quotes are used for
subshells? Gah!

I have written a shell which I call fish, that fixes all the above
problems except the last one. The shell syntax is slightly different
from POSIX but still sucks (Set environment variables using the 'set'
builtin). Mostly the syntax for if/for/while is pretty bad.

I would really like to support X copy and paste whenever the DISPLAY
variable is set, but whenever I try to read the ICCCM manuals my eyes
start bleeding.

The reason why I wrote a new shell instead of patching i.e. bash is
that the changes I propose are pretty deep, and it seemed much easier
to implement them on a small and simple system first. Implementing
syntax highlighting would require large changes to both readline and
bash, for instance. As would implementing tab completion of wildcarded
options. And BTW, the bash source code is.... a bit difficult to read.
Now that I've gotten fish into a workable state, it should be easier
to move over some of these changes to another shell. If these changes
would be accepted, that is.

fish has been tested under Solaris 9 and Fedora Core 3 and 1, it
probably contains a million bugs and special code to explode your
monitor, but I use it on my machine every day. If you are interested,
fish is available under the GPL on http://roo.no-ip.org/fish/, you can
download the source in tar.gz, tar.bz2 or srpm form, or an i386 rpm.

Feedback, bug reports, build problems, flames etc are all welcome.

Axel Liljencrantz

Chris F.A. Johnson

2005-02-15, 6:02 pm

On Tue, 15 Feb 2005 at 10:35 GMT, Axel Liljencrantz wrote:
> I've long been irked by how much shells like bash and zsh seem to
> focus on scriptability, when I spend 90 % of my time in front of a
> shell using it interactively.

When you consider that even a simple command IS a script, it makes
sense.

> Among the features I've missed in modern shells are:
>
> * Good terminal handling,

Bash works well for me.

> like detecting when a background process has
> written output and automatically redraw the prompt,

??

> using terminfo to make sure backspace and delete will work more
> often,

Not a problem with bash.

> writing process exit notifications as soon as a process
> exits, etc, etc.

I wouldn't want it interrupting what I'm doing, and pop-ups would
be enough to make me throw it out.

> * Discoverability. After using UNIX for 10 years, I still find out new
> features of Bash. I friendlier help system, preferably easy to find
> help in HTML format.

Great, if you can set it so that a single argument to a command
brings up the page, as in "man fish", or "htmlman fish".

> * Better tab completion. I hate the fact that I can't use tab
> completion on file arguments containing wildcards. I love programable
> completions, but few people use them, since they're not enabled by
> default.

They are on Mandrake.

> * When displaying a list of possible completions, wouln't it be nice
> with a description of each completion, like 'Character device' or
> 'Manual page'? This is even more useful when combined with the
> programable completions of options. Cant remember the option to set
> the ssh encryption algorithm? Type 'ssh -' and double tap on tab, and
> a nice list of all ssh options, with short descriptions appear.

Nice (apart from the colour).

> * A useable pager for displaying long lists of tab completions. zsh
> jus prints all the completions, even if they won't fit. Bash uses a
> really bad pager. The pager should be able to scroll up and down both
> lines and pages at a time, and it the user starts typing, the pager
> should exit without consuming the output.

Looks good (apart from the awful colour).

> * Syntax highligting. Pretty colors by themselves don't add very much,
> but combined with a bit of error detection, this is useful. Errors
> like reading from a non existant file, issuing a non-existant command
> should be highlighted.

I like it.

> * A syntax that doesn't suck. OK, so a shell for scripting should
> probably be POSIX compliant, but a interactive shell should focus on
> beeing actually useable.

For me, being usable means having the syntax that I use in scripts
(which I spend a good deal of time writing) available at the
command prompt.

> This is 2005, and writing 'foo = bar' doesn't work? And how
> intuitive is it that an environment variable with spaces is
> separated into multiple arguments unless it is quoted?

Changing it could break many scripts.

> Single quotes and double quotes are used for two different kinds of
> quoting while backticks, which look nearly identical to quotes are
> used for subshells? Gah!

That's why there's $(...) instead of `...`.

> I have written a shell which I call fish, that fixes all the above
> problems except the last one. The shell syntax is slightly different
> from POSIX but still sucks (Set environment variables using the 'set'
> builtin). Mostly the syntax for if/for/while is pretty bad.

While I like some of the features, it is of no use to me unless
it uses POSIX syntax.

> I would really like to support X copy and paste whenever the DISPLAY
> variable is set, but whenever I try to read the ICCCM manuals my eyes
> start bleeding.

I can copy and paste OK in a terminal window.

> The reason why I wrote a new shell instead of patching i.e. bash is
> that the changes I propose are pretty deep, and it seemed much easier
> to implement them on a small and simple system first. Implementing
> syntax highlighting would require large changes to both readline and
> bash, for instance. As would implementing tab completion of wildcarded
> options. And BTW, the bash source code is.... a bit difficult to read.
> Now that I've gotten fish into a workable state, it should be easier
> to move over some of these changes to another shell. If these changes
> would be accepted, that is.
>
> fish has been tested under Solaris 9 and Fedora Core 3 and 1, it
> probably contains a million bugs and special code to explode your
> monitor, but I use it on my machine every day. If you are interested,
> fish is available under the GPL on http://roo.no-ip.org/fish/, you can
> download the source in tar.gz, tar.bz2 or srpm form, or an i386 rpm.
>
> Feedback, bug reports, build problems, flames etc are all welcome.

It built, but when I try to use it:

$ ./fish
fish: Invalid multibyte sequence
: Invalid argument
fish: Invalid multibyte sequence
: Invalid or incomplete multibyte or wide character
Welcome to fish, the friendly interactive shell
/info/home/chris/src/fish-1.0>

I installed it from RPM on Mandrake 10.1, and it works.

I recommend that you write a man page, even if all it does is point
to the HTML docs.

The best thing would be to write the docs in a format that can be
transformed to any other format (DocBook, perhaps?).

--
Chris F.A. Johnson http://cfaj.freeshell.org/shell
========================================
===========================
My code (if any) in this post is copyright 2005, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License

liljencrantz@gmail.com

2005-02-15, 6:02 pm

Chris F.A. Johnson wrote:
> On Tue, 15 Feb 2005 at 10:35 GMT, Axel Liljencrantz wrote:
>
> When you consider that even a simple command IS a script, it makes
> sense.

For people like you, who write lots of scripts, yes. Me, I write maybe
five or ten shell scripts a year. I don't care that the same program
that I use as a shell is also used to implement a hundred different
commands. I want a good shell for interactive use.

>
>
> Bash works well for me.

Bash works ok, but could be improved. I will explain below.

>
>
> ??

If a process has been executed in the foreground and then put in the
background (like grep foo *.c <ENTER>^zbg<ENTER> ), it can still write
stuff to the screen. If this happens, fish will detect it and repaint
the prompt.

>
>
> Not a problem with bash.

SSH from Fedora to a Solaris machine, and neither backspace or delete
works with bash. At least not on the Solaris 9 machines I've used.

>
>
> I wouldn't want it interrupting what I'm doing, and pop-ups would
> be enough to make me throw it out.

Oh, I agree 100%. The notifications in fish are just like the ones bash
emits when you press enter, only they are printed whenever the job
ends, instead of waiting for you to press enter. After a notification
event is printed, the commandline is repainted, so you are never ever
interrupted, and the commandline always diplays what you are doing. Try
the command 'sleep 5', and compare the behaviour of fish with that of
bash.

>
new[vbcol=seagreen]
>
> Great, if you can set it so that a single argument to a command
> brings up the page, as in "man fish", or "htmlman fish".

Exactly. Fish uses the help command, since that is used by many other
commandline applications like ftp, etc. So write 'help bg' to display a
HTML help page on the bg builtin. This is even more useful since tab
completion offers a list of all help sections with a short description.

>
programable[vbcol=seagreen]
>
> They are on Mandrake.
>

Didn't know that. Score one for Mandrake! Any more distros do this?

nice[vbcol=seagreen]
and[vbcol=seagreen]
>
> Nice (apart from the colour).

Yeah, sorry about the colors. The colors for the commandline are all
user configurable, colors for the pager will be user configurable in
the next release. I should really put together a more tasteful default
for the next release as well.

>
both[vbcol=seagreen]
>
> Looks good (apart from the awful colour).

Same as above.

>
much,[vbcol=seagreen]
command[vbcol=seagreen]
>
> I like it.

Thanks!

>
on[vbcol=seagreen]
>
> For me, being usable means having the syntax that I use in
scripts
> (which I spend a good deal of time writing) available at the
> command prompt.

Yes, I guess that is true for some people. Ideally, now that I have
written fish, it would be nice to port all the good features to bash or
zsh. Not a lot of fun, though. At least bash has some pretty strange
code.

>
>
> Changing it could break many scripts.

Yep. Friendly _interactive_ shell...

>
>
> That's why there's $(...) instead of `...`.

Yep. But I still encounter the backticks a lot. And the other issues
still stand.

>
different[vbcol=seagreen]
'set'[vbcol=seagreen]
>
> While I like some of the features, it is of no use to me unless
> it uses POSIX syntax.

Like I said above. Implementing fish features in other shells would be
nice.

>
DISPLAY[vbcol=seagreen]
eyes[vbcol=seagreen]
>
> I can copy and paste OK in a terminal window.

OK, maybe I wasn't very clear. The terminal emulator does let you copy
and paste between X applications. What I mean is that I would like the
shells own killring (Accesed through ^K) connected to the X clipboard.
Not a huge deal, but it would be cool.

>
easier[vbcol=seagreen]
and[vbcol=seagreen]
wildcarded[vbcol=seagreen]
read.[vbcol=seagreen]
easier[vbcol=seagreen]
changes[vbcol=seagreen]
interested,[vbcol=seagreen]
can[vbcol=seagreen]
rpm.[vbcol=seagreen]
>
> It built, but when I try to use it:
>
> $ ./fish
> fish: Invalid multibyte sequence
> : Invalid argument
> fish: Invalid multibyte sequence
> : Invalid or incomplete multibyte or wide character
> Welcome to fish, the friendly interactive shell
> /info/home/chris/src/fish-1.0>

OK, that is weird. That probably means that fish tries to perform
globbing using file which contains characters that are illegal in your
character set. Do you have any such files in your home directory or in
/etc? Does the RPM display the same messages?

>
> I installed it from RPM on Mandrake 10.1, and it works.
>

Great!

>
> I recommend that you write a man page, even if all it does is
point
> to the HTML docs.
>
> The best thing would be to write the docs in a format that can be
> transformed to any other format (DocBook, perhaps?).

The manuals are written as Doxygen sourcecode annotations. Doxygen has
a man-page output module, so I should be able to do that with a little
effort. Don't know if the man-page should be the whole help text or
just a short message about how to use the HTML help.

Thank you for taking the time to test fish and commant on it's
behavior.

Axel

>
>
> --
> Chris F.A. Johnson
http://cfaj.freeshell.org/shell
>
========================================
===========================
> My code (if any) in this post is copyright 2005, Chris F.A.
Johnson
> and may be copied under the terms of the GNU General Public
License

bsh

2005-02-15, 6:02 pm

Chris F.A. Johnson wrote:
> On Tue, 15 Feb 2005 at 10:35 GMT, Axel Liljencrantz wrote:
[vbcol=seagreen]
> Changing it could break many scripts.

No!

Because of a little-used construct called a "variable
assignment list" that is possible in k/sh, one _cannot_
have entrained semicolon(s) because of its original purpose
to define per-process environment variables. That is:

var1=a var2=b var3= # no semicolons nec in a v.a.l. !
var1=a; var2=b; var3= # most people do this
# define additional env vars as v.a.l. before /path/app
var1=a var2=b var3= /path/app options...

Obviously, any semicolon would disallow the v.a.l. from
being semantically "attached" to the /path/app invocation,
and "floating" equal-signs would make the parsing ambiguous.

The kludge of mandating spaces in csh either around _both_
sides of the equal sign or none at all, is a terrible idea.
The c-shell-ism of optional whitespace around the equal
sign always was syntactically problematic, if you ask me....

=Brian

Faux_Pseudo

2005-02-16, 2:48 am

_.-In comp.unix.shell, Axel Liljencrantz wrote the following -._
> I've long been irked by how much shells like bash and zsh seem to
> focus on scriptability, when I spend 90 % of my time in front of a
> shell using it interactively.

I tend to script anything I do more than once a week. And when I am
interactive I am always thinking about how I would script the command
because I may have to do that latter.

> * A useable pager for displaying long lists of tab completions. zsh
> jus prints all the completions, even if they won't fit. Bash uses a
> really bad pager. The pager should be able to scroll up and down both
> lines and pages at a time, and it the user starts typing, the pager
> should exit without consuming the output.

I don't like that idea. If I have a pager I am going to want it to
act like the default pager on the system, in my case less.

> * Syntax highligting. Pretty colors by themselves don't add very much,
> but combined with a bit of error detection, this is useful. Errors
> like reading from a non existant file, issuing a non-existant command
> should be highlighted.

I am fully with you on this one. In fact I made a post about it years
ago in this group. I would love to be able to have error messages in
a different color.

> * A syntax that doesn't suck. OK, so a shell for scripting should
> probably be POSIX compliant, but a interactive shell should focus on
> beeing actually useable. This is 2005, and writing 'foo = bar' doesn't
> work? And how intuitive is it that an environment variable with spaces
> is separated into multiple arguments unless it is quoted?

This would break lots of scripts. And I want the behaviour as it is
because to me it is intuative. What you are asking for is easy to
accomplish with things like this:
while read line ; do foo "$line" done < file
Otherwise we would have to write a seperate function to split lines up
when it is needless.

> Single
> quotes and double quotes are used for two different kinds of quoting
> while backticks, which look nearly identical to quotes are used for
> subshells? Gah!

That is depreciated. Most shells will now do $() instead of ``
because it makes nesting and (human) parsing much easier.

> I would really like to support X copy and paste whenever the DISPLAY
> variable is set

Sometimes I want that and sometimes I don't. I tend to juggle
screen's, X's and the shells copy buffer. While sometimes I think it
would be nice to highlight something in X and then ^Y it in the shell
there are too many times when I know that would be a bad idea.
> options. And BTW, the bash source code is.... a bit difficult to read.

It can't be worse then the bash man page.

I may tell people to
RTFM a lot but I never tell them to RTFM man bash. I will usually
find a better writen bit that is just about the issue they are having
or I will c&p the relivent section of the man page.

> Feedback, bug reports, build problems, flames etc are all welcome.

Any shell that sets out to do things you are trying is a good idea.
The usable bits will be ported into other shells even if you stop
development a week from now.

--
.-')) asciipr0n.com/fp ('-. | It's a damn poor mind that
' ..- .:" ) ( ":. -.. ' | can only think of one way to
((,,_;'.;' UIN=66618055 ';. ';_,,)) | spell a word.
((_.YIM=Faux_Pseudo :._)) | - Andrew Jackson

Faux_Pseudo

2005-02-16, 2:48 am

_.-In comp.unix.shell, liljencrantz@gmail.com wrote the following -._
> Oh, I agree 100%. The notifications in fish are just like the ones bash
> emits when you press enter, only they are printed whenever the job
> ends, instead of waiting for you to press enter. After a notification
> event is printed, the commandline is repainted, so you are never ever
> interrupted, and the commandline always diplays what you are doing. Try
> the command 'sleep 5', and compare the behaviour of fish with that of
> bash.

Ok now that that is better explained I like it. I would request one
improvement though. Once in a while I do something like
$ foo.sh &
and forget it is there until I go back and check on it after a while
and wonder why it hasn't finished. It would be better if the script
or interactive command was waiting for input if the shell let me know
even if I have redirected all output to /dev/null. Also if when I
typed jobs (which is a built in in bash) if it let me know what the
cpu usage of the backgrounded command was (or given the nanosecond
gaps of cpu usage in a process an average of the last second or so
would be nice) so that if it was 00% and I know it should be much
higher than that I know I should be debugging it.

>
> Yep. Friendly _interactive_ shell...

Unfortunatly if people are interactive in one shell and then go to
write in another shell problems happen. Ask any csh user.

>
> Yep. But I still encounter the backticks a lot. And the other issues
> still stand.

That is because backticks are the old standerd and it is taking a
while for people to get used to the new one. Anytime I see someone
use `` instead of $() I update them one why the later is better than
the former and they start using it from that point forward.
One issue I noted was that all the books and guids still use `` and
then foot note that $() is out there. Eventually they will start
using $() by default and foot noting about ``.

--
.-')) asciipr0n.com/fp ('-. | It's a damn poor mind that
' ..- .:" ) ( ":. -.. ' | can only think of one way to
((,,_;'.;' UIN=66618055 ';. ';_,,)) | spell a word.
((_.YIM=Faux_Pseudo :._)) | - Andrew Jackson

William Park

2005-02-16, 2:48 am

Axel Liljencrantz <liljencrantz@gmail.com> wrote:
> I've long been irked by how much shells like bash and zsh seem to
> focus on scriptability, when I spend 90 % of my time in front of a
> shell using it interactively.

....

> I have written a shell which I call fish, that fixes all the above
> problems except the last one. The shell syntax is slightly different
> from POSIX but still sucks (Set environment variables using the 'set'
> builtin). Mostly the syntax for if/for/while is pretty bad.

I don't want to throw cold water... but, syntax matters. I can live
without Tab completion of command options, because I know all the
options that I'm going to use, or I can look them up beforehand. But,
Bourne syntax should be preserved.

You simplified single/double quotes on one hand, but added complicated
situation on the other hand. Eg.
for i a b c "echo $i"
is not improvement over standard Bourne syntax,
for i in a b c; do
echo $i
done
How do you implement
for i in a b c; do
echo $i
sleep 5
echo $i.xxx
done
using Fish syntax?

Your syntax for 'if', 'for', and 'while' is unusually complicated,
because command has to be quoted as single unit. Also, most notably,
'case' statement is missing from Fish.

>
> I would really like to support X copy and paste whenever the DISPLAY
> variable is set, but whenever I try to read the ICCCM manuals my eyes
> start bleeding.
>
> The reason why I wrote a new shell instead of patching i.e. bash is
> that the changes I propose are pretty deep, and it seemed much easier
> to implement them on a small and simple system first. Implementing
> syntax highlighting would require large changes to both readline and
> bash, for instance. As would implementing tab completion of wildcarded
> options. And BTW, the bash source code is.... a bit difficult to read.

I believe you!

> Now that I've gotten fish into a workable state, it should be easier
> to move over some of these changes to another shell. If these changes
> would be accepted, that is.
>
> fish has been tested under Solaris 9 and Fedora Core 3 and 1, it
> probably contains a million bugs and special code to explode your
> monitor, but I use it on my machine every day. If you are interested,
> fish is available under the GPL on http://roo.no-ip.org/fish/, you can
> download the source in tar.gz, tar.bz2 or srpm form, or an i386 rpm.
>
> Feedback, bug reports, build problems, flames etc are all welcome.

I'm running Slackware-9.1. I downloaded Doxygen, but couldn't compile
it. So, I downloaded binary 'fish-1.1-1.i386.rpm', and installed it.

When I invoke ./fish, I get screenful of
complete: Too many arguments
fish.d/fish_complete.fish(line 240): complete -c gcc -o ftemplate-depth-1 -d Set\ maximum\ template\ depth\ to $i

All in all, it's refreshing to see some action in shell development.
Perhaps, when you get Bourne syntax done, you can incorporate my patches
to Bash (http://freshmeat.net/projects/bashdiff/). :-)

CC'ed.
--
William Park <opengeometry@yahoo.ca>, Toronto, Canada
Slackware Linux -- because I can type.

liljencrantz@gmail.com

2005-02-16, 2:48 am

Faux_Pseudo wrote:
> _.-In comp.unix.shell, Axel Liljencrantz wrote the following -._
>
> I tend to script anything I do more than once a week. And when I am
> interactive I am always thinking about how I would script the command
> because I may have to do that latter.

Well, my goal has never been to make a shell which is bad for
scripting. :-) I just want a shell with lots of interactive features
and a sane syntax. The latter I don't have yet, but I plan on making it
sane.

>
both[vbcol=seagreen]
>
> I don't like that idea. If I have a pager I am going to want it to
> act like the default pager on the system, in my case less.

Seeing how zsh doesn't have a pager, bash has a pager that only lets
you scroll down, and fish has a pager that lets you scroll up/down
lines or pages using the arrow keys and page up/down, I'd say that fish
has the most less-like pager. But the thought of actually using the
default pager for paging completions has crossed my mind.

>
much,[vbcol=seagreen]
command[vbcol=seagreen]
>
> I am fully with you on this one. In fact I made a post about it
years
> ago in this group. I would love to be able to have error messages in
> a different color.
>

on[vbcol=seagreen]
doesn't[vbcol=seagreen]
spaces[vbcol=seagreen]
>
> This would break lots of scripts. And I want the behaviour as it is
> because to me it is intuative. What you are asking for is easy to
> accomplish with things like this:
> while read line ; do foo "$line" done < file
> Otherwise we would have to write a seperate function to split lines
up
> when it is needless.

Well, I know how to accomplish it, but I just feel that it should be
the default. I'd much prefer if the bahaviour that is unintuitive to me
(splitting up variables) was not the default behaviour.

>
quoting[vbcol=seagreen]
>
> That is depreciated. Most shells will now do $() instead of ``
> because it makes nesting and (human) parsing much easier.
>
DISPLAY[vbcol=seagreen]
>
> Sometimes I want that and sometimes I don't. I tend to juggle
> screen's, X's and the shells copy buffer. While sometimes I think it
> would be nice to highlight something in X and then ^Y it in the shell
> there are too many times when I know that would be a bad idea.

Given the mess that is the primary buffer and X clipboard, I guess that
wouldn't even happen. Selecting copies to the primary buffer, and ^Y
should probably use the clipboard. I don't know. Anyway, since fish has
an emacs-style killring, if you accidentaly overwrote your copy, just
use Meta-Y to rotate to the correct string.

read.[vbcol=seagreen]
>
> It can't be worse then the bash man page.

I may tell people to
> RTFM a lot but I never tell them to RTFM man bash. I will usually
> find a better writen bit that is just about the issue they are having
> or I will c&p the relivent section of the man page.

Oh it can't, can it? Keep in mind that the bash man page was written to
be readable, understandable documentation. The bash code is written by
the same people, but for the purpose of doing clever obscure things to
be portable to any system, including ancient non-POSIX ones.

>
>
> Any shell that sets out to do things you are trying is a good idea.
> The usable bits will be ported into other shells even if you stop
> development a week from now.

Let's hope so. I really like some of the features in fish.

Axel

>
> --
> .-')) asciipr0n.com/fp ('-. | It's a damn poor mind that
> ' ..- .:" ) ( ":. -.. ' | can only think of one way
to
> ((,,_;'.;' UIN=66618055 ';. ';_,,)) | spell a word.
> ((_.YIM=Faux_Pseudo :._)) | - Andrew Jackson

liljencrantz@gmail.com

2005-02-16, 7:55 am

William Park wrote:
> Axel Liljencrantz <liljencrantz@gmail.com> wrote:
>
> ...
>
different[vbcol=seagreen]
'set'[vbcol=seagreen]
>
> I don't want to throw cold water... but, syntax matters. I can live
> without Tab completion of command options, because I know all the
> options that I'm going to use, or I can look them up beforehand.
But,
> Bourne syntax should be preserved.

You will have to convince me that the Bourne syntax should be
preserved. In my opinion, it is bad enough that it should be replaced.
I have not focused on syntax in fish, so I'm not saying this is what
should replace it, but the Bourne syntax has enough strangeness in it
that I feel it should go. Very few people use Fortran 77 today, and C99
is a different beast from what C looked like 30 years ago.

>
> You simplified single/double quotes on one hand, but added
complicated
> situation on the other hand. Eg.
> for i a b c "echo $i"
> is not improvement over standard Bourne syntax,
> for i in a b c; do
> echo $i
> done
> How do you implement
> for i in a b c; do
> echo $i
> sleep 5
> echo $i.xxx
> done
> using Fish syntax?

You could write 'for i a b c "echo $i; sleep 5; echo $i.xxx"', but I
freely admit that this is a very bad, ugly syntax.

>
> Your syntax for 'if', 'for', and 'while' is unusually complicated,
> because command has to be quoted as single unit. Also, most notably,
> 'case' statement is missing from Fish.
>

All correct. I plan on implementing a sane syntax for for/while/if, but
haven't gotten around to it yet. I'm not sure exactly how a case
statement should look, but there is obviously a need for one.

DISPLAY[vbcol=seagreen]
eyes[vbcol=seagreen]
easier[vbcol=seagreen]
and[vbcol=seagreen]
wildcarded[vbcol=seagreen]
read.[vbcol=seagreen]
>
> I believe you!
>
easier[vbcol=seagreen]
changes[vbcol=seagreen]
interested,[vbcol=seagreen]
can[vbcol=seagreen]
rpm.[vbcol=seagreen]
>
> I'm running Slackware-9.1. I downloaded Doxygen, but couldn't
compile
> it. So, I downloaded binary 'fish-1.1-1.i386.rpm', and installed it.
>
> When I invoke ./fish, I get screenful of
> complete: Too many arguments
> fish.d/fish_complete.fish(line 240): complete -c gcc -o
ftemplate-depth-1 -d Set\ maximum\ template\ depth\ to $i

DOH! A small typo in an init file. Just comment out (using #) line 240
of '/etc/fish.d/fish_complete.fish', and that'll be the end of it.
Sorry.

>
> All in all, it's refreshing to see some action in shell development.
> Perhaps, when you get Bourne syntax done, you can incorporate my
patches
> to Bash (http://freshmeat.net/projects/bashdiff/). :-)

Here's that way I see it:

Most people who are scripting in bash are not using the bourne syntax
or even the POSIX syntax. They are using lots and lots of strange
bash-isms. So what I need to implement to satisfy all the scripters is
the bash syntax. It would probably be far less error prone to use the
bash parser directly than trying to emulate it in fish. So then I
should either port the interesting features of fish to bash or rip out
the bash parser and put it into fish. I would guess the latter would be
the easier of the two, but you never know.

But like I said, you'd have to convince me that the bash syntax is good
enough to be saved. I feel there are enough mistakes in it to warrant
something new.

I looked at the bashdiff homepage. A lot of nice syntactic sugar, but
why should i.e. match be a builtin? If it was implemented as a regular
command, it would be useable in any shell, bugs in it would not crash
the terminal, and it wouldn't be subject to bashes strange quirks with
regards to piping builtins. And why should the clients to postgres,
mysql, awk and Python be embedded in the shell? The way I see it the
shells strength is that it can easily interact with other commands,
that can perform specialized tasks like database lookup, mathematics,
etc.

Axel

>
> CC'ed.
> --
> William Park <opengeometry@yahoo.ca>, Toronto, Canada
> Slackware Linux -- because I can type.

liljencrantz@gmail.com

2005-02-16, 7:55 am

Faux_Pseudo wrote:
> _.-In comp.unix.shell, liljencrantz@gmail.com wrote the following -._
bash[vbcol=seagreen]
notification[vbcol=seagreen]
ever[vbcol=seagreen]
Try[vbcol=seagreen]
of[vbcol=seagreen]
>
> Ok now that that is better explained I like it. I would request one
> improvement though. Once in a while I do something like
> $ foo.sh &
> and forget it is there until I go back and check on it after a while
> and wonder why it hasn't finished. It would be better if the script
> or interactive command was waiting for input if the shell let me know
> even if I have redirected all output to /dev/null. Also if when I
> typed jobs (which is a built in in bash) if it let me know what the
> cpu usage of the backgrounded command was (or given the nanosecond
> gaps of cpu usage in a process an average of the last second or so
> would be nice) so that if it was 00% and I know it should be much
> higher than that I know I should be debugging it.

Hmmm... If I understand the first request correctly, you want to know
when a script has stopped, waiting for input. If a background job is
trying to read from the terminal, it should recieve a SIGTTIN signal
and stop. This should be caught by fish and a notification should be
printed. I just tried doing a "emacs -nw &" in fish and got a "Job 0,
'emacs &' has stopped" notification message. Is that what you mean?

As to the second, i can see the use of that. Fish also has a jobs
builtin, it works like the one in bash. (As do the fg and bg builtins,
but the % before job id or job name is required) There is AFAIK no
portable way of doing this. There might be an unportable way under
Linux, the proc filesystem has a utime field containing the number of
jiffies of CPU time a process has had. Whether this is usable for
determining CPU activity I don't know. Notice that CPU monitors like
Top take a while to start up so they can get accurate readings over
time for their output. Wouldn't want the jobs command to pause for half
a second to perform CPU meassurements. Might be possible and worth the
effort.

>
>
> Unfortunatly if people are interactive in one shell and then go to
> write in another shell problems happen. Ask any csh user.

True... Nothing is perfect. Least of all csh.

>
issues[vbcol=seagreen]
>
> That is because backticks are the old standerd and it is taking a
> while for people to get used to the new one. Anytime I see someone
> use `` instead of $() I update them one why the later is better than
> the former and they start using it from that point forward.
> One issue I noted was that all the books and guids still use `` and
> then foot note that $() is out there. Eventually they will start
> using $() by default and foot noting about ``.

That situation might resolve itself, but the other issues I outlined
are real problems that are hard to fix without breaking the syntax.

Axel

>
> --
> .-')) asciipr0n.com/fp ('-. | It's a damn poor mind that
> ' ..- .:" ) ( ":. -.. ' | can only think of one way
to
> ((,,_;'.;' UIN=66618055 ';. ';_,,)) | spell a word.
> ((_.YIM=Faux_Pseudo :._)) | - Andrew Jackson

liljencrantz@gmail.com

2005-02-16, 7:55 am

What are you talking about?

liljencrantz@gmail.com

2005-02-16, 7:55 am

Chris F.A. Johnson wrote:
> On Wed, 16 Feb 2005 at 09:23 GMT, liljencrantz@gmail.com wrote:
> [snip]
replaced.[vbcol=seagreen]
what[vbcol=seagreen]
it[vbcol=seagreen]
C99[vbcol=seagreen]
>
> All languages have their quirks. The Bourne syntax was developed
> for a purpose, and it serves that purpose well.
>
> It is the language in which many thousands of scripts are
written;
> it is a language which is well known. It has survived ksh and
> bash.
>

Maybe. But mostly, the arguments for Posix I've heard boil down to
"it's there". No one is saying the Bourne syntax is good. All I hear is
different versions of "I can live with it". I'd like to try doing a
sane syntax and see what happens. If the difference in conveniance for
people isn't worth the extra effort of learning different language, I
guess I'll have to go the Posix path. But it seems to me that new
scripting lanuages pop up all the time (Python, Ruby, etc) and the same
goes with regular programing languages. Why not have a little
development when it comes to scripting languages?

development.[vbcol=seagreen]
syntax[vbcol=seagreen]
>
> The bashisms are extensions to the Bourne shell; the underlying
> syntax is the same.
>
> When Apress asked me to write a book of shell scripts last
> summer, the editor asked whether it should be geared to bash or
> ksh or zsh or whatever. I said it should be POSIX scripts, with
> some using bash or ksh extensions when it made sense to do so.
>
> Out of 150 to 200 scripts, only a handful (probably fewer than
> 10) use bashisms. (Some functions definitions depend on which
> shell is running the script, and define the appropriate one.)

OK. That's not what my experience tells me, but you obviously have a
great deal more shell scripting experience than me, so there must be
something to what you are saying.

>
>
> No, implement the POSIX standard, possibly with extensions.
>
> [snip]
good[vbcol=seagreen]
warrant[vbcol=seagreen]
>
> There are idiosyncracies, not mistakes.
>
but[vbcol=seagreen]
>
> ITYM "e.g. match".

Yep. I do make a lot of typos. I always preview my comments, but I am a
lousy proofreader. Speaking of typos, I uploaded a new version of fish,
version 1.1.1, which I hope fixes the error messages you saw on
startup. If you'd give it a spin, I'd be grateful.

Axel

>
> --
> Chris F.A. Johnson
http://cfaj.freeshell.org/shell
>
========================================
===========================
> My code (if any) in this post is copyright 2005, Chris F.A.
Johnson
> and may be copied under the terms of the GNU General Public
License

William Park

2005-02-16, 5:57 pm

liljencrantz@gmail.com <liljencrantz@gmail.com> wrote:
> Chris F.A. Johnson wrote:
>
> Maybe. But mostly, the arguments for Posix I've heard boil down to
> "it's there". No one is saying the Bourne syntax is good. All I hear is
> different versions of "I can live with it". I'd like to try doing a
> sane syntax and see what happens. If the difference in conveniance for
> people isn't worth the extra effort of learning different language, I
> guess I'll have to go the Posix path. But it seems to me that new
> scripting lanuages pop up all the time (Python, Ruby, etc) and the same
> goes with regular programing languages. Why not have a little
> development when it comes to scripting languages?

Putting it that way, you have a point. But, current syntax is a bit
inadequate. Wouldn't it be easier to dissect Ash shell, and use what
you need?

--
William Park <opengeometry@yahoo.ca>, Toronto, Canada
Slackware Linux -- because I can type.

liljencrantz@gmail.com

2005-02-16, 5:57 pm

William Park wrote:
> liljencrantz@gmail.com <liljencrantz@gmail.com> wrote:
developed[vbcol=seagreen]
survived[vbcol=seagreen]
hear is[vbcol=seagreen]
for[vbcol=seagreen]
I[vbcol=seagreen]
same[vbcol=seagreen]
>
> Putting it that way, you have a point. But, current syntax is a bit
> inadequate. Wouldn't it be easier to dissect Ash shell, and use what
> you need?

Thank you for understanding my point of view. If I go down the Posix
path, I'm sure I'll do it by merging the parser of another shell with
the UI of fish. A clever person would have known that talking about a
new shell on comp.unix.shell would lead to a lot of focus on the
syntax. But I've never said I was clever! I mostly wanted to implement
a syntax which was somewhat logical while remaining easy to parse (fish
syntax is dead easy to parse) so that I could try out syntax
highlighting, error detection, etc. I have spent comparatively little
time working on parsing, syntax, etc. That said, I have a pretty clear
idea of exacly how I want to write the code for implementing a syntax
for writing sane looking conditionals like

if test -f foo.txt
echo foo.txt exists
else
echo foo.txt does not exist
end

for i in *.c
grep \#include $i
end

while test -f foo.txt
echo no foo
sleep 5m
end

On a sidenode, I plan on adding automatic indentation to scripts.
Should be a nice reminder of where in the code you are.

Another addition, which is much, much harder, but would be cool is if
you could move around and edit any part of a multiline statement until
the last 'end' token has been written. This would require the fish
editor to become a fullblown multiline editor,hey - people have written
editors before...

I'm off to a conference in Taipei tomorrow, I'll be back in one week.
Won't be able to hack while I'm there, but I'll find an Internet Caf=E9
for correspondance.

Axel

>
> --
> William Park <opengeometry@yahoo.ca>, Toronto, Canada
> Slackware Linux -- because I can type.

Barry Margolin

2005-02-16, 8:48 pm

In article <1108547046.786812.80070@c13g2000cwb.googlegroups.com>,
"liljencrantz@gmail.com" <liljencrantz@gmail.com> wrote:

> What are you talking about?

What are *you* talking about? There's no context to your message.

Please use Options->Reply so that you quote the message you're replying
to.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

liljencrantz@gmail.com

2005-02-17, 7:52 am

Barry Margolin wrote:
> In article <1108547046.786812.80070@c13g2000cwb.googlegroups.com>,
> "liljencrantz@gmail.com" <liljencrantz@gmail.com> wrote:
>
>
> What are *you* talking about? There's no context to your message.
>
> Please use Options->Reply so that you quote the message you're
replying
> to.
>
> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***

Sorry. I've just switched to the new version of Google groups, I'm not
100 % used to it.

I was replying to the post by Alan Connor calling me a nimwit with
loose screws. Maybe he was right. :-/

Axel

Faux_Pseudo

2005-02-18, 2:48 am

_.-In comp.unix.shell, liljencrantz@gmail.com wrote the following -._
> I was replying to the post by Alan Connor calling me a nimwit with
> loose screws. Maybe he was right. :-/

If you say Alan Connor might have been right again I will plonk you
as fast as my processor will let me.

--
.-')) asciipr0n.com/fp ('-. | It's a damn poor mind that
' ..- .:" ) ( ":. -.. ' | can only think of one way to
((,,_;'.;' UIN=66618055 ';. ';_,,)) | spell a word.
((_.YIM=Faux_Pseudo :._)) | - Andrew Jackson

Stephane CHAZELAS

2005-02-20, 6:19 pm

2005-02-15, 02:35(-08), Axel Liljencrantz:
> I've long been irked by how much shells like bash and zsh seem to
> focus on scriptability, when I spend 90 % of my time in front of a
> shell using it interactively.

It may be true for bash, not for zsh, to my mind. zsh is interactive
mode oriented. It also has a powerful programming language, but that's
for extending it, a great part of zsh features is written in zsh.

> Among the features I've missed in modern shells are:
>
> * Good terminal handling, like detecting when a background process has
> written output and automatically redraw the prompt

The way you're doing it works only if the process outputs something the
second after you press a key. You can have the same in zsh if you put
something like:

zmodload -i zsh/{stat,parameter}
check-terminal() {
local -a t
stat -f0 -A t +mtime
(( t[1] != old_tty_mtime[1] )) && zle redisplay
zle -F 9 post-check-terminal
}
post-check-terminal() {
stat -f0 -A old_tty_mtime +mtime
zle -F 9 2> /dev/null
}
exec 9< /dev/zero
zle -F 0 check-terminal
functions[precmd]+='
stat -f0 -A old_tty_mtime +mtime
'

to your ~/.zshrc.

> using terminfo to
> make sure backspace and delete will work more often

terminfo is often not helpfull in that regard. Querying the
terminal might help, but few terminals support that.

With zsh, you have the $terminfo special associative array (and
echoti), so you can do whatever you want in your ~/.zshrc to
fix the <Backspace> handling (note that zsh maps both ^H and ^?
to backward-delete-char by default).

You can add:

(( $+terminfo[kdch1] )) && bindkey $terminfo[kdch1] delete-char

to your ~/.zshrc if you want <Delete> to delete the character under the
cursor.

>, writing process
> exit notifications as soon as a process exits, etc, etc.

zsh does that by default (and it's configurable).

> * Discoverability. After using UNIX for 10 years, I still find out new
> features of Bash. I friendlier help system, preferably easy to find
> help in HTML format.

Ever heard of info and its index/table of content, look up
facilities?

info predates HTML of many years and is better suited for manuals.

Also note that bash has a "help" builtin, ksh93 has builtin --man for
instance, see info -f zsh -n Utilities for zsh online help access.

> * Better tab completion. I hate the fact that I can't use tab
> completion on file arguments containing wildcards. I love programable
> completions, but few people use them, since they're not enabled by
> default.

If people don't use programable completions because it is not activated
by default, then they won't use fish if it's not installed by default.

You may want to try zsh new completion system. Search for
compinstall in the manual or have a look at zsh user guide.

> * When displaying a list of possible completions, wouln't it be nice
> with a description of each completion, like 'Character device' or
> 'Manual page'? This is even more useful when combined with the
> programable completions of options. Cant remember the option to set
> the ssh encryption algorithm? Type 'ssh -' and double tap on tab, and
> a nice list of all ssh options, with short descriptions appear.

zsh completion system does that.

~$ cvs a<Tab>
add -- add a new file/directory to the repository
admin -- administration front end for rcs
annotate -- show last revision where each line was modified

~$ ssh -<Tab>
-1 -- forces ssh to try protocol version 1 only
-2 -- forces ssh to try protocol version 2 only
-4 -- forces ssh to use IPv4 addresses only
-6 -- forces ssh to use IPv6 addresses only

it can add suffixes to files as ls -F or colors as ls --color.

You can have category descriptions as well. Run
autoload compinstall; compinstall
and follow the instructions.

>
> * A useable pager for displaying long lists of tab completions. zsh
> jus prints all the completions, even if they won't fit. Bash uses a
> really bad pager. The pager should be able to scroll up and down both
> lines and pages at a time, and it the user starts typing, the pager
> should exit without consuming the output.

You obviously missed the complist module with its color completion
browser (not only pager).

>
> * Syntax highligting. Pretty colors by themselves don't add very much,
> but combined with a bit of error detection, this is useful. Errors
> like reading from a non existant file, issuing a non-existant command
> should be highlighted.

That's a useful feature of your fish, I agree.

zsh has some error detection and correction support but it's more
intrusive as it asks questions to the user.

I generally rely on zsh completion approximation features that can
correct what you type (only when you press tab so that it is not
annoying).

> * A syntax that doesn't suck. OK, so a shell for scripting should
> probably be POSIX compliant, but a interactive shell should focus on
> beeing actually useable. This is 2005, and writing 'foo = bar' doesn't
> work?

foo = bar

runs "foo" with two arguments "=" and "bar", as I expect.

Assignments are shaped on the values of the environment. If you put "foo
= bar" in the environment, then you assign " bar" to the "foo "
variable.

> And how intuitive is it that an environment variable with spaces
> is separated into multiple arguments unless it is quoted?

not in zsh.

> Single
> quotes and double quotes are used for two different kinds of quoting
> while backticks, which look nearly identical to quotes are used for
> subshells? Gah!

you should use $(...) instead of `...` then.

But I agree shell syntax is often very awkward. Look at rc for a cleaner
syntax.

> I have written a shell which I call fish, that fixes all the above
> problems except the last one. The shell syntax is slightly different
> from POSIX but still sucks (Set environment variables using the 'set'
> builtin). Mostly the syntax for if/for/while is pretty bad.
>
> I would really like to support X copy and paste whenever the DISPLAY
> variable is set, but whenever I try to read the ICCCM manuals my eyes
> start bleeding.

I see what you mean.

Note mouse support for zsh at http://stchaz.free.fr/. It relies on
xterm-like mouse tracking support or on Linux GPM, not on X selection,
so that it allows cursor positionning as well.

--
Stéphane

Stephane CHAZELAS

2005-02-20, 6:19 pm

2005-02-16, 01:23(-08), liljencrantz@gmail.com:
[...]
> You will have to convince me that the Bourne syntax should be
> preserved. In my opinion, it is bad enough that it should be replaced.

See the "rc" plan9 shell for a better syntax.

No, Bourne syntax is:

for i in a b c; do
echo "$i"
done
[vbcol=seagreen]
> You could write 'for i a b c "echo $i; sleep 5; echo $i.xxx"', but I
> freely admit that this is a very bad, ugly syntax.

zsh has the perl-like:

for i (a b c) {echo $i; sleep 5; echo $i.xxx}

(as well as the POSIX one).

In rc:

for (i in a b c) {echo $i; sleep 5; echo $i.xxx}

[...]
> But like I said, you'd have to convince me that the bash syntax is good
> enough to be saved. I feel there are enough mistakes in it to warrant
> something new.

I agree, but except a bit for csh, non-Bourne syntaxes never
took off.

Note zsh way: fixing syntax awkwardnesses and provide a POSIX
mode for compatibility.

--
Stéphane

liljencrantz@gmail.com

2005-02-20, 6:19 pm

Stephane CHAZELAS wrote:
> 2005-02-15, 02:35(-08), Axel Liljencrantz:
>
> It may be true for bash, not for zsh, to my mind. zsh is interactive
> mode oriented. It also has a powerful programming language, but
that's
> for extending it, a great part of zsh features is written in zsh.

I've used zsh a bit and I agree it's a lot nicer than bash. But I never
realised how many wonderfull things are disabled by default.

>
has[vbcol=seagreen]
>
> The way you're doing it works only if the process outputs something
the
> second after you press a key. You can have the same in zsh if you put
> something like:

Huh? The way I do it, whenever a child process dies, a signal handler
is called, which interrupts the read() function, which will check for
new job notifications and print them to the terminal. How does that
ever stop working after a few seconds?

>
> zmodload -i zsh/{stat,parameter}
> check-terminal() {
> local -a t
> stat -f0 -A t +mtime
> (( t[1] !=3D old_tty_mtime[1] )) && zle redisplay
> zle -F 9 post-check-terminal
> }
> post-check-terminal() {
> stat -f0 -A old_tty_mtime +mtime
> zle -F 9 2> /dev/null
> }
> exec 9< /dev/zero
> zle -F 0 check-terminal
> functions[precmd]+=3D'
> stat -f0 -A old_tty_mtime +mtime
> '

Doesn't the stat command have one second precision? That would mean any
output which is caught would have to be further than one second away
from user activity to be caught. Or am I missing something? Can't test
anything that advanced right now, since I'm on the wrong side of the
world.

>
> to your ~/.zshrc.
>
>
> terminfo is often not helpfull in that regard. Querying the
> terminal might help, but few terminals support that.

Not my experience. Terminfo seems to get backspace and delete right for
almost any system in my experience, but maybe i'm lucky. Can't help but
feel that hardcoding the escape sequences into every program is an
extreme kludge. Terminfo is there on any modern system, if it is
broken, lets fix it instead of special casing the shell.

>
> With zsh, you have the $terminfo special associative array (and
> echoti), so you can do whatever you want in your ~/.zshrc to
> fix the <Backspace> handling (note that zsh maps both ^H and ^?
> to backward-delete-char by default).
>
> You can add:
>
> (( $+terminfo[kdch1] )) && bindkey $terminfo[kdch1] delete-char
>
> to your ~/.zshrc if you want <Delete> to delete the character under
the
> cursor.
>
>
> zsh does that by default (and it's configurable).

Cool. When was this added? When I started working on fish (3 years
ago), I don't belive that functionality was there. Goes for a lot of
the things you've shown.

>
new[vbcol=seagreen]
>
> Ever heard of info and its index/table of content, look up
> facilities?
>
> info predates HTML of many years and is better suited for manuals.
>
> Also note that bash has a "help" builtin, ksh93 has builtin --man for
> instance, see info -f zsh -n Utilities for zsh online help access.

Yes, I've heard of info. What I hear is that no one likes info. How
many people use it? Really? In a graphical environment, which is 90% of
all use cases, a graphical webbrowser with a visual history, good font
rendering, type-ahead find, tabbed browsing, images and style sheet
support and thousands of other features is miles ahead of info, in my
opinion.

Are you seriously saying that the average user, who uses the web almost
every day but never touches an info file would be better of learning an
old, keyboard and terminal based system which does exactly the same
thing only differently? Sounds like a bad way of leveraging existing
user knowledge.

>
programable[vbcol=seagreen]
>
> If people don't use programable completions because it is not
activated
> by default, then they won't use fish if it's not installed by
default.

True. Very true.

>
> You may want to try zsh new completion system. Search for
> compinstall in the manual or have a look at zsh user guide.
>
>
nice[vbcol=seagreen]
and[vbcol=seagreen]
>
> zsh completion system does that.
>
> ~$ cvs a<Tab>
> add -- add a new file/directory to the repository
> admin -- administration front end for rcs
> annotate -- show last revision where each line was modified

Awesome. Had no idea. How long has that been there?

>
> ~$ ssh -<Tab>
> -1 -- forces ssh to try protocol version 1 only
> -2 -- forces ssh to try protocol version 2 only
> -4 -- forces ssh to use IPv4 addresses only
> -6 -- forces ssh to use IPv6 addresses only
>
> it can add suffixes to files as ls -F or colors as ls --color.
>
> You can have category descriptions as well. Run
> autoload compinstall; compinstall
> and follow the instructions.
>
both[vbcol=seagreen]
>
> You obviously missed the complist module with its color completion
> browser (not only pager).

How does one enable it? Honestly, seems someone on the zsh team has had
many of the same ideas I've had and implemented them quicker than me.
Bastard! ;-) Shame he didn't make them enabled by default, so people
would actually USE them.

>
much,[vbcol=seagreen]
command[vbcol=seagreen]
>
> That's a useful feature of your fish, I agree.
>
> zsh has some error detection and correction support but it's more
> intrusive as it asks questions to the user.
>
> I generally rely on zsh completion approximation features that can
> correct what you type (only when you press tab so that it is not
> annoying).

Yeah, that is what got me to start thinking about syntax highlighting.
The way zsh does it, you have to stop up and ask yourself "Hmmm, did i
mistype that command?" and manually ask the computer. No one I know
does that. Glancing at the screen and thinking "Hey, that's an ugly red
splotch on the screen" is someting that I could do.

>
on[vbcol=seagreen]
doesn't[vbcol=seagreen]
>
> foo =3D bar
>
> runs "foo" with two arguments "=3D" and "bar", as I expect.
>
> Assignments are shaped on the values of the environment. If you put
"foo
> =3D bar" in the environment, then you assign " bar" to the "foo "
> variable.

Having "foo =3D bar" and "foo=3Dbar" do different things is a really,
really bad idea. Whitespace sensitive languages are always much harder
to read. That is NOT just my idea, read any textbook on language
design, read up on famous errors caused by whitespace bugs, etc.

>
>
> not in zsh.

Huh? What do you know... Great!

>
quoting[vbcol=seagreen]
>
> you should use $(...) instead of `...` then.

Yes, I always do. But backticks seem to be used by a lot of OTHER
people, making scripts hard to read. The fact that I never use them
makes it that much harder to remember that they are used by others.

>
> But I agree shell syntax is often very awkward. Look at rc for a
cleaner
> syntax.

Maybe I sould implement the rc syntax in fish?

>
different[vbcol=seagreen]
'set'[vbcol=seagreen]
DISPLAY[vbcol=seagreen]
eyes[vbcol=seagreen]
>
> I see what you mean.
>
> Note mouse support for zsh at http://stchaz.free.fr/. It relies on
> xterm-like mouse tracking support or on Linux GPM, not on X
selection,
> so that it allows cursor positionning as well.

Cool. Can't look it up now, but I'll have to look in to it.

BTW, latest zsh on my computer does not support UTF8. Is that still
true? Would be a shame.

Thanks for all the cool info on zsh.

Axel

>=20
> --=20
> St=E9phane

Stephane CHAZELAS

2005-02-20, 6:19 pm

2005-02-19, 10:04(-08), liljencrantz@gmail.com:
[...]
> has
> the
>
> Huh? The way I do it, whenever a child process dies, a signal handler
> is called, which interrupts the read() function, which will check for
> new job notifications and print them to the terminal. How does that
> ever stop working after a few seconds?

I meant that if a background process writes something to the
terminal, fish won't detect it, and thus won't refresh the
prompt if it writes it the same second as the last key pressed.

[...]
[...][vbcol=seagreen]
> Doesn't the stat command have one second precision? That would mean any
> output which is caught would have to be further than one second away
> from user activity to be caught. Or am I missing something? Can't test
> anything that advanced right now, since I'm on the wrong side of the
> world.

Yes, as in fish, that's exactly what I meant. That zsh code
mimics the way I understood fish worked.

[...]
>
> Not my experience. Terminfo seems to get backspace and delete right for
> almost any system in my experience, but maybe i'm lucky. Can't help but
> feel that hardcoding the escape sequences into every program is an
> extreme kludge. Terminfo is there on any modern system, if it is
> broken, lets fix it instead of special casing the shell.

That's not the problem. For instance, xterm may send a different
character for backspace, depending on what it thinks the default
value of the tty driver "erase" character is (see
ptyInitialErase resource for xterm). And "kbs" for the xterm
terminfo entry will be either ^H or ^? depending on the system.
So, if you rlogin or telnet from one flavour of system to
another, telnet or rlogin won't always translate the characters
(AFAIK, GNU inetutils telnet won't do it by default), so as
$TERM is the same all along, there will be one system where it's
not correct (zsh mapping both ^? and ^H to backward-delete-char
is then a good compromise).

[...]
>
> Cool. When was this added? When I started working on fish (3 years
> ago), I don't belive that functionality was there. Goes for a lot of
> the things you've shown.

Yes, 8 years ago at least, it was already like that.
unsetopt notify to disable it (same as in tcsh).
It seems it has already been there (maybe not always enabled by
default, as in tcsh).

> Yes, I've heard of info. What I hear is that no one likes info. How
> many people use it? Really? In a graphical environment, which is 90% of
> all use cases, a graphical webbrowser with a visual history, good font
> rendering, type-ahead find, tabbed browsing, images and style sheet
> support and thousands of other features is miles ahead of info, in my
> opinion.

Without the index with completion and the ability to search the
entire manual, it's not in my opinion. See:

Type:
$ info zsh
<...info started...>
i
<...index prompt...>
comp<Tab>

>
> Are you seriously saying that the average user, who uses the web almost
> every day but never touches an info file would be better of learning an
> old, keyboard and terminal based system which does exactly the same
> thing only differently? Sounds like a bad way of leveraging existing
> user knowledge.

Sounds to me that a shell is a terminal based system anyway.

[...]
>
> Awesome. Had no idea. How long has that been there?

The new completion system was introduced in the 3.1.x versions,
some years ago.

[...]
>
> How does one enable it? Honestly, seems someone on the zsh team has had
> many of the same ideas I've had and implemented them quicker than me.
> Bastard! ;-) Shame he didn't make them enabled by default, so people
> would actually USE them.

See compinstall

info -f zsh --index-search=compinstall

[...]
> Having "foo = bar" and "foo=bar" do different things is a really,
> really bad idea. Whitespace sensitive languages are always much harder
> to read. That is NOT just my idea, read any textbook on language
> design, read up on famous errors caused by whitespace bugs, etc.

Yes. rc is space insensitive.

I like it the way it is in Bourne like shells because it's a
very close mapping to the execve(2) syscall.

foo=a empty= bar=b cmd arg1 arg2

and the x=x args go into envp and the other ones into argp. In
early shells, both type of arguments could even be intersperced
(now the envp ones must come first).

With a space insensitive shell, you'd have to be careful for
the:

empty= cmd arg

That should be witten instead:

empty= '' cmd arg

[...]
> cleaner
>
> Maybe I sould implement the rc syntax in fish?

Why not, you would have a working basis. rc has been ported to
POSIX OS.

What I'd like to see in rc:

a double quote support similar to PERL one: variables are
expanded within (using $" for joining fields) and the litereal
\n, \t... are expanded (instead of the stupid thing in
Bourne-like shells where it's the applications (echo, print,
awk) that expand them (often differently and not portably).

fixing command substitution so that one (and only one contrary
to other shells where everyone is removed) trailing newline
character is removed.

[...]
> selection,
>
> Cool. Can't look it up now, but I'll have to look in to it.
>
> BTW, latest zsh on my computer does not support UTF8. Is that still
> true? Would be a shame.
[...]

It's currently being implemented (see zsh-workers mailing list)
and there's some early support already.

Note that other shells support (bash and ksh93 at least) is
quite incomplete yet, to say the least.

--
Stéphane

Stephane CHAZELAS

2005-02-20, 6:19 pm

2005-02-19, 10:04(-08), liljencrantz@gmail.com:
[...]
>
> Cool. When was this added? When I started working on fish (3 years
> ago), I don't belive that functionality was there. Goes for a lot of
> the things you've shown.

Some dates

- $var not subject to word splitting and filename generation,
and $(cmd) not subject to filename generation: always been
there I think (1990). It's the most FAdQ for zsh.
- notify (of bg processes): 1990 (I guess it has always been there)
- complist (completion browser)
discription of completions
completion of cvs with descriptions
headers describing what is being completed
1998-1999 when the new completion system was introduced. That
was a time when I would check every other day if there was a
new release as every one was bringing incredible new features.
they were development releases, that may be why you missed
them (even if some Linux distribution were distributing it).
4.0.1 (stable branch) was released in June 2001, though.
- zle -F (possibility to add file descriptor handlers to the
line editor (used in Linux console mouse support)): 2004 ;)
- UTF8 support: I'm confident it will have a proper support in
2005.

--
Stéphane

Stephane CHAZELAS

2005-02-20, 6:19 pm

2005-02-19, 19:02(+00), Stephane CHAZELAS:
> 2005-02-19, 10:04(-08), liljencrantz@gmail.com:
[...]
>
> Yes, 8 years ago at least, it was already like that.
> unsetopt notify to disable it (same as in tcsh).
> It seems it has already been there (maybe not always enabled by
> default, as in tcsh).

In fact, ksh and bash do that as well if you issue a set -b or
set -o notify, it's a POSIX feature. However, contrary to zsh,
they don't redraw the prompt after the notification is
displayed.

--
Stéphane

Stephane CHAZELAS

2005-02-20, 6:19 pm

2005-02-16, 04:43(+00), Faux_Pseudo:
> _.-In comp.unix.shell, liljencrantz@gmail.com wrote the following -._
>
> Ok now that that is better explained I like it. I would request one
> improvement though. Once in a while I do something like
> $ foo.sh &
> and forget it is there until I go back and check on it after a while
> and wonder why it hasn't finished. It would be better if the script
> or interactive command was waiting for input if the shell let me know
> even if I have redirected all output to /dev/null. Also if when I
> typed jobs (which is a built in in bash) if it let me know what the
> cpu usage of the backgrounded command was (or given the nanosecond
> gaps of cpu usage in a process an average of the last second or so
> would be nice) so that if it was 00% and I know it should be much
> higher than that I know I should be debugging it.
[...]

With zsh 4.2.x, on Linux you can do (put in ~/.zshrc for
instance):

# BEGIN
typeset -F SECONDS # floating point SECONDS
typeset -A cpu_times # recorded cpu times
typeset -F last_status_time
zmodload -i zsh/parameter
autoload -U colors
colors
[[ $functions[precmd] = *output-job-status* ]] ||
functions[precmd]+='
: output-job-status
emulate -L zsh
if (( $#jobstates )); then
local -a p
local i j s t st
local -F u
print -rn -- $fg_no_bold[blue]
s=$SECONDS
for j in ${(k)jobstates}; do
IFS=: eval "p=(\${=jobstates[\$j]})"
printf >&2 "%1s%%%-2d%50s[%c]:" "$p[2]" $j "${jobtexts[$j]}" ${(U)p[1]}
for i in $p[3,-1]; do
pid=${i%%\=*}
if IFS=" " read -rA st < /proc/$pid/stat; then
(( t = ${(j,+,)st[14,17]} ))
(( u = (t - cpu_times[$pid]) / (s - last_status_time)))
(( u >= bold_cpu_threshold )) && print -rn -- $fg_bold[red]
printf " %5d[%c]%2.1f%%" $pid ${(U)i#*=} $u
(( u >= bold_cpu_threshold )) && print -rn -- $fg_no_bold[blue]
cpu_times[$pid]=$t
fi
done
print
done
last_status_time=$s
print -rn $reset_color
fi
'
bold_cpu_threshold=10 # display in bold cpu usage above 10%
# END

it will display the status of the background tasks above the
prompt in blue (on terminals supporting ANSI colors) with the
percentage of cpu usage for every process between two prompt
displays (in bold red if above 10%).

--
Stéphane

Stephane CHAZELAS

2005-02-20, 6:19 pm

2005-02-15, 14:21(-08), bsh:
> Chris F.A. Johnson wrote:
>
>
> No!
>
> Because of a little-used construct called a "variable
> assignment list" that is possible in k/sh, one _cannot_
> have entrained semicolon(s) because of its original purpose
> to define per-process environment variables. That is:
>
> var1=a var2=b var3= # no semicolons nec in a v.a.l. !
> var1=a; var2=b; var3= # most people do this
> # define additional env vars as v.a.l. before /path/app
> var1=a var2=b var3= /path/app options...
>
> Obviously, any semicolon would disallow the v.a.l. from
> being semantically "attached" to the /path/app invocation,
> and "floating" equal-signs would make the parsing ambiguous.
>
> The kludge of mandating spaces in csh either around _both_
> sides of the equal sign or none at all, is a terrible idea.
> The c-shell-ism of optional whitespace around the equal
> sign always was syntactically problematic, if you ask me....
[...]

rc has no problem with

; a = 1 b = 2 c = '' env | grep '^[abc]='
a=1
b=2
c=

--
Stéphane

Stephane CHAZELAS

2005-02-20, 6:19 pm

2005-02-16, 04:29(+00), Faux_Pseudo:
[...]
>
> This would break lots of scripts.

But that would fix many more of them. Most people forget to
quote variables when it is necessary.
And I want the behaviour as it is

> because to me it is intuative. What you are asking for is easy to
> accomplish with things like this:
> while read line ; do foo "$line" done < file

I guess you meant:

while IFS= read -r line; do foo -- "$line"; done ;)

> Otherwise we would have to write a seperate function to split lines up
> when it is needless.

Or simply as in zsh: $=foo (or ${=foo}) instead of $foo.

[...]
> Sometimes I want that and sometimes I don't. I tend to juggle
> screen's, X's and the shells copy buffer. While sometimes I think it
> would be nice to highlight something in X and then ^Y it in the shell
> there are too many times when I know that would be a bad idea.

With zsh, you can put the X cut buffer into the zsh cutbuffer
with:

get-X-cut-buffer() {
killring=("$CUTBUFFER" "${(@)killring[1,-2]}")
CUTBUFFER=$(awk "BEGIN{$(xprop -root -notype CUT_BUFFER0)
print CUT_BUFFER0}")
}
zle -N get-X-cut-buffer
bindkey '^[[2;5~' get-X-cut-buffer

^[[2;5~ is the character sequence sent upon pressing
<Ctrl-Insert> in my xterm.

(<Ctrl-Y> to yank (paste) the cutbuffer in zsh emacs mode)

or again, you can use zsh mouse support (not related to X
selection) at http://stchaz.free.fr/mouse.zsh

--
Stéphane

liljencrantz@gmail.com

2005-02-20, 6:19 pm

William Park

2005-02-20, 6:19 pm

Barry Margolin

2005-02-21, 2:48 am

liljencrantz@gmail.com

2005-02-21, 2:48 am

Faux_Pseudo

2005-02-22, 5:52 pm

Boyd Adamson

2005-02-23, 2:51 am

Stephane CHAZELAS <this.address@is.invalid> writes:

> 2005-02-19, 19:02(+00), Stephane CHAZELAS:
> [...]
>
> In fact, ksh and bash do that as well if you issue a set -b or
> set -o notify, it's a POSIX feature. However, contrary to zsh,
> they don't redraw the prompt after the notification is
> displayed.

I'd like to see a set -o notify-like behaviour that only reported
immediately if I was at a prompt, but otherwise waited for a program to
exit. Otherwise, I tend to miss the notification in the scrolling output
of another command.

Stephane CHAZELAS

2005-02-25, 2:51 am

2005-02-23, 16:11(+11), Boyd Adamson:
[...]
>
> I'd like to see a set -o notify-like behaviour that only reported
> immediately if I was at a prompt, but otherwise waited for a program to
> exit. Otherwise, I tend to miss the notification in the scrolling output
> of another command.

With zsh:

zmodload -i zsh/parameter
functions[preexec]+='
setopt nonotify
'
functions[precmd]+='
setopt notify
'

Or you can have it report it twice or intelligently by analysing
$jobstates in precmd() and maybe defining a TRAPCHLD() function.

--
Stéphane

liljencrantz@gmail.com

2005-02-25, 7:57 am

Stephane CHAZELAS wrote:
> 2005-02-19, 10:04(-08), liljencrantz@gmail.com:

[=2E..]

any[vbcol=seagreen]
away[vbcol=seagreen]
test[vbcol=seagreen]
the[vbcol=seagreen]
>
> Yes, as in fish, that's exactly what I meant. That zsh code
> mimics the way I understood fish worked.
>

Nope. Fish is more clever in two ways.

* On systems which implement futimes (*BSD), it uses it to set the
update time one second off, which will mean that all output is always
caught.

* On systems which have microsecond precision in fstat (Almost all),
use the extra precision to get a one microsecond window of uncaught
output.

As you can see, the odds of undetected tampering are much smaller in
fish. This is only nitpicking, the one second precision is all right
most of the time.

[=2E..]
for[vbcol=seagreen]
but[vbcol=seagreen]
>
> That's not the problem. For instance, xterm may send a different
> character for backspace, depending on what it thinks the default
> value of the tty driver "erase" character is (see
> ptyInitialErase resource for xterm). And "kbs" for the xterm
> terminfo entry will be either ^H or ^? depending on the system.
> So, if you rlogin or telnet from one flavour of system to
> another, telnet or rlogin won't always translate the characters
> (AFAIK, GNU inetutils telnet won't do it by default), so as
> $TERM is the same all along, there will be one system where it's
> not correct (zsh mapping both ^? and ^H to backward-delete-char
> is then a good compromise).

Ouch. No good solution? *bleh*

>
90% of[vbcol=seagreen]
font[vbcol=seagreen]
my[vbcol=seagreen]
>
> Without the index with completion and the ability to search the
> entire manual, it's not in my opinion. See:
>
> Type:
> $ info zsh
> <...info started...>
> i
> <...index prompt...>
> comp<Tab>

Ok, so you like info. I don't. I think most people don't.

>
almost[vbcol=seagreen]
learning an[vbcol=seagreen]
existing[vbcol=seagreen]
>
> Sounds to me that a shell is a terminal based system anyway.

If you are using a shell from inside a virtual terminal in X, I see no
reason why the gui should not be taken advantage of. It would be much
more user friendly to use nicely typeset, graphical help environment.
Another possible features is tooltip-like windows showing possible
completions as you are typing.

[=2E..]
harder[vbcol=seagreen]
>
> Yes. rc is space insensitive.
>
> I like it the way it is in Bourne like shells because it's a
> very close mapping to the execve(2) syscall.

I don't because of the white-space sensetive syntax. To each his own.

>
> foo=3Da empty=3D bar=3Db cmd arg1 arg2
>
> and the x=3Dx args go into envp and the other ones into argp. In
> early shells, both type of arguments could even be intersperced
> (now the envp ones must come first).
>
> With a space insensitive shell, you'd have to be careful for
> the:
>
> empty=3D cmd arg
>
> That should be witten instead:
>
> empty=3D '' cmd arg
>
> [...]
>
> Why not, you would have a working basis. rc has been ported to
> POSIX OS.
>
> What I'd like to see in rc:
>
> a double quote support similar to PERL one: variables are
> expanded within (using $" for joining fields) and the litereal
> \n, \t... are expanded (instead of the stupid thing in
> Bourne-like shells where it's the applications (echo, print,
> awk) that expand them (often differently and not portably).
>
> fixing command substitution so that one (and only one contrary
> to other shells where everyone is removed) trailing newline
> character is removed.

I will look in to the rc syntax.

>
> [...]
> [...]
>
> It's currently being implemented (see zsh-workers mailing list)
> and there's some early support already.
>
> Note that other shells support (bash and ksh93 at least) is
> quite incomplete yet, to say the least.

As far as i know, the unicode support in fish is 100% complete. :-)

Axel

>=20
>=20
> --=20
> St=E9phane

liljencrantz@gmail.com

2005-02-25, 7:57 am

Boyd Adamson wrote:

[...]
>
> I'd like to see a set -o notify-like behaviour that only reported
> immediately if I was at a prompt, but otherwise waited for a program
to
> exit. Otherwise, I tend to miss the notification in the scrolling
output
> of another command.

Right. fish already does exactly what you describe. Sorry for not
beeing more detailed in my explanation in the first place.

Axel

liljencrantz@gmail.com

2005-02-28, 8:01 am

Stephane CHAZELAS wrote:
[...]
had[vbcol=seagreen]
me.[vbcol=seagreen]
people[vbcol=seagreen]
>
> See compinstall
>
> info -f zsh --index-search=compinstall

Thank you for the tip. Skimmed through the manual, but I couldn't find
any section on a completion pager. What I did find was this:

"pager - The nslookup function looks up this style in the context
`:nslookup' to determine the program used to display output that does
not fit on a single screen."

Which means that you can use any pager, like less, as the zsh pager for
large completion lists. Which is nice. But I still prefer the fish
pager since when you have scrolled down to the completion you wanted,
you can just start typing in your completion in and the pager will quit
with no unneeded keystrokes.

Axel

liljencrantz@gmail.com

2005-03-01, 6:04 pm

Stephane CHAZELAS wrote:
[=2E..]
it[vbcol=seagreen]
shell[vbcol=seagreen]
>
> With zsh, you can put the X cut buffer into the zsh cutbuffer
> with:
>
> get-X-cut-buffer() {
> killring=3D("$CUTBUFFER" "${(@)killring[1,-2]}")
> CUTBUFFER=3D$(awk "BEGIN{$(xprop -root -notype CUT_BUFFER0)
> print CUT_BUFFER0}")
> }
> zle -N get-X-cut-buffer
> bindkey '^[[2;5~' get-X-cut-buffer
>
> ^[[2;5~ is the character sequence sent upon pressing
> <Ctrl-Insert> in my xterm.
>
> (<Ctrl-Y> to yank (paste) the cutbuffer in zsh emacs mode)
>
> or again, you can use zsh mouse support (not related to X
> selection) at http://stchaz.free.fr/mouse.zsh
>
> --
> St=E9phane

I didn't know about the xprop command. I have used the information you
gave me to implement seamless X-windows clipboard support for both
copying and pasting integrated into the fish killring. It works the
same way as emacs does now.

I'll make a release with support for this and better syntax for
for/while/if in a week or so.

Big thanks for the pointer.

Axel

Stephane CHAZELAS

2005-03-01, 6:04 pm

2005-02-28, 01:53(-08), liljencrantz@gmail.com:
[...]
>
> Thank you for the tip. Skimmed through the manual, but I couldn't find
> any section on a completion pager. What I did find was this:
>
> "pager - The nslookup function looks up this style in the context
> `:nslookup' to determine the program used to display output that does
> not fit on a single screen."
>
> Which means that you can use any pager, like less, as the zsh pager for
> large completion lists. Which is nice. But I still prefer the fish
> pager since when you have scrolled down to the completion you wanted,
> you can just start typing in your completion in and the pager will quit
> with no unneeded keystrokes.
[...]

Hi Axel,

No, nslookup is an example user function that puts a wrapper
around nslookup to provide zsh line editor to dumb command lines
like nslookup's. It demonstrates the zpty module.

What I was talking about is more than a pager (just as info is
more than a pager compared to man ;).

It's available when, in compinstall interactive menu, you select:

3. Styles for changing the way completions are displayed and inserted.

and then (sub-menu):

3. Configure coloured/highlighted completion lists, selection of items
and scrolling.

then for instance:

2. Use cursor keys to select completions from completion lists.

That involves the complist zsh module that provides a completion
browser (you visually select the completion with cursor keys,
color is provided, you can go to next/previous page, do
incremental searches...).

You may want to try all the submenus to see what behavior suits
you best. You can also have a look at the documentation for the
complist module in zsh info pages:

info -f zsh -n 'The zsh/complist Module'

--
Stéphane

Stephane CHAZELAS

2005-03-01, 6:04 pm

2005-03-1, 07:11(-08), liljencrantz@gmail.com:
[...]
> I didn't know about the xprop command. I have used the information you
> gave me to implement seamless X-windows clipboard support for both
> copying and pasting integrated into the fish killring. It works the
> same way as emacs does now.
[...]

Hi Axel.

Note that CUT_BUFFERs are generally considered as a deprecated
way to exchange data between X applications. Newer X terminals
such as Gnome or KDE terminals don't even implement it.

You may prefer using selections. There are non-standard
utilities to manipulate selections: you may find xsel or xlip
for instance (http://www.vergenet.net/~conrad/software/xsel/
http://people.debian.org/~kims/xclip/xclip-0.08.tar.gz)

It's a bit more complicated to embed in the shell, as while
CUT_BUFFERs are X properties residing in the X server, the
selection is handled by the application selection owner so you'd
need to implement a X handler within the shell that answers to
selection requests (xsel or xlip put themselves in the
background until somebody else claims the selection ownership to
do that).

For zsh mouse and selection support
(http://stchaz.free.fr/mouse.zsh), I used the CLIPBOARD
selection via xsel or xclip whichever is available.
Additionnaly, for terminals that don't already do it by
themselves, upon pressing <Ctrl-Insert>, I put the X PRIMARY
selection onto the CLIPBOARD or if that selection is empty, I
put the value of CUT_BUFFER0 instead.

For a good documentation on all this, you may have a look at:
http://www.ac3.edu.au/SGI_Developer...html/index.html
see also
http://www.ac3.edu.au/SGI_Developer...ml#S1-1002-12-4

--
Stéphane

liljencrantz@gmail.com

2005-03-02, 7:51 am

Stephane CHAZELAS wrote:
> 2005-03-1, 07:11(-08), liljencrantz@gmail.com:
> [...]
you[vbcol=seagreen]
> [...]
>
> Hi Axel.
>
> Note that CUT_BUFFERs are generally considered as a deprecated
> way to exchange data between X applications. Newer X terminals
> such as Gnome or KDE terminals don't even implement it.
>

Doh. It just had to be harder than that, didn't it? Thank you for the
information. I'd already noticed that fish copy and paste only worked
with some applications, now I know why.

> You may prefer using selections. There are non-standard
> utilities to manipulate selections: you may find xsel or xlip
> for instance (http://www.vergenet.net/~conrad/software/xsel/
> http://people.debian.org/~kims/xclip/xclip-0.08.tar.gz)
>
> It's a bit more complicated to embed in the shell, as while
> CUT_BUFFERs are X properties residing in the X server, the
> selection is handled by the application selection owner so you'd
> need to implement a X handler within the shell that answers to
> selection requests (xsel or xlip put themselves in the
> background until somebody else claims the selection ownership to
> do that).

Looked in to xsel/xclip, they seem easy and painless to use. I'll try
to reimplement the feature.

>
> For zsh mouse and selection support
> (http://stchaz.free.fr/mouse.zsh), I used the CLIPBOARD
> selection via xsel or xclip whichever is available.
> Additionnaly, for terminals that don't already do it by
> themselves, upon pressing <Ctrl-Insert>, I put the X PRIMARY
> selection onto the CLIPBOARD or if that selection is empty, I
> put the value of CUT_BUFFER0 instead.

Zsh mouse is a very cool feature. Congratulations for coming up with
and implementing the idea. But I can't help wondering about the button
3 behaviour. The behaviour after clicking button 1 or 2 is an intuitive
tweak of the default behaviour and it is what most GUI-based editors
do, but pressing button 3 usually brings up a menu. Should that
behaviour really be changed?

Axel

>
> For a good documentation on all this, you may have a look at:
>
http://www.ac3.edu.au/SGI_Developer...html/index.html