Re: Optimal emacs shell for coding

Re: Optimal emacs shell for coding

[Xah]

On Aug 11, 4:38 am, Jonathan Groll <li...@groll.co.za> wrote:
> I know of only three ways to get an emacs shell:
>
> M-x terminal-emulator
> M-x shell
> M-x eshell
> (There is also M-x shell-command RET)
>
> Question is, which one is best for coding? Lately I've found myself
> opening up an xterm session to do miscellaneous coding support tasks -
> and am mostly struggling with different readline history keybindings
> (eg. I'm used to entering C-r at a shell to get (reverse-i-search) -
> obviously in an emacs shell this will have a dfferent outcome to what
> I desire!
>
> Any recommendations?

They really all have different purposs.


• M-x shell-command
lets you run a single shell cammand.

• M-x shell
command line interface to OS.

• M-x terminal-emulator

This is actually a terminal emulator.
For example, you can start a telnet or ssh or top in it.
You can also start a vi, or even emacs itself within.

You cannot run these problems with M-x shell, for example.

• M-x eshell
This is just like shell, except it's written in elisp.
The purpose is so that you can have access to the familiar unix shell
in different OSes such as MS Windows.

In general, the shell-command and shell is most useful. Run eshell if
you are in Windows and don't have cygwin installed and want to run
unix commands such as ls, cd, mkdir, etc. If you need to run telnet,
ssh, top, or any program that fills a screen, you'll need to run term.
I don't particular recommend it because once in term, many default
keybindings of emacs won't work because it pretends to be a term emu.
If you want to run ssh etc, best to start in a real term emulator.

For more tips, see
http://xahlee.org/emacs/emacs_unix.html

  Xah
∑ http://xahlee.org/

☄

Re: Optimal emacs shell for coding

[Lennart Borgman (gmail)]

Xah wrote:
> In general, the shell-command and shell is most useful. Run eshell if
> you are in Windows and don't have cygwin installed and want to run
> unix commands such as ls, cd, mkdir, etc. If you need to run telnet,


Have you tried for example "grep" from within eshell? Quite nice.

Re: Optimal emacs shell for coding

[Xah]

On Aug 11, 8:24 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> wrote:
> Xahwrote:
> > In general, the shell-command and shell is most useful. Run eshell if
> > you are in Windows and don't have cygwin installed and want to run
> > unix commands such as ls, cd, mkdir, etc. If you need to run telnet,
>
> Have you tried for example "grep" from within eshell? Quite nice.

Let me see...

-----------------------------

Welcome to the Emacs shell


~/web/emacs $ which grep
eshell/grep is a compiled Lisp function in `em-unix.el'
~/web/emacs $ ls | grep lin
elisp_link_report.el                        modernization.html
elisp_link_report.el~
modernization_html_mail.html
elisp_link_report.html
modernization_meta_key.html
elisp_make_link.html                        ms_keyboard
emacs_installing_packages.html              wrap-url2.html.gz
emacs_manual_problem.html                   xah_emacs_linkify.el
emacs_n_unicode.html                        xah_emacs_linkify.el~
~/web/emacs $

-----------------------------

LOL.

Get back to work Len.

  Xah
∑ http://xahlee.org/

☄

Re: Optimal emacs shell for coding

[Lennart Borgman (gmail)]

Xah wrote:
> On Aug 11, 8:24 am, "Lennart Borgman (gmail)"
> <lennart.borg...@gmail.com> wrote:
>> Xahwrote:
>>> In general, the shell-command and shell is most useful. Run eshell if
>>> you are in Windows and don't have cygwin installed and want to run
>>> unix commands such as ls, cd, mkdir, etc. If you need to run telnet,
>> Have you tried for example "grep" from within eshell? Quite nice.
> 
> Let me see...
> 
> -----------------------------
> 
> Welcome to the Emacs shell
> 
> 
> ~/web/emacs $ which grep
> eshell/grep is a compiled Lisp function in `em-unix.el'
> ~/web/emacs $ ls | grep lin
> elisp_link_report.el                        modernization.html
> elisp_link_report.el~
> modernization_html_mail.html
> elisp_link_report.html
> modernization_meta_key.html
> elisp_make_link.html                        ms_keyboard
> emacs_installing_packages.html              wrap-url2.html.gz
> emacs_manual_problem.html                   xah_emacs_linkify.el
> emacs_n_unicode.html                        xah_emacs_linkify.el~
> ~/web/emacs $
> 
> -----------------------------
> 
> LOL.
> 
> Get back to work Len.


Why do you think predictable behaviour is nice? ;-)

Ok, you discovered the bug so it is your turn to file a bug report again ...

Re: Optimal emacs shell for coding

[Tim X]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Xah wrote:
>> On Aug 11, 8:24 am, "Lennart Borgman (gmail)"
>> <lennart.borg...@gmail.com> wrote:
>>> Xahwrote:
>>>> In general, the shell-command and shell is most useful. Run eshell if
>>>> you are in Windows and don't have cygwin installed and want to run
>>>> unix commands such as ls, cd, mkdir, etc. If you need to run telnet,
>>> Have you tried for example "grep" from within eshell? Quite nice.
>>
>> Let me see...
>>
>> -----------------------------
>>
>> Welcome to the Emacs shell
>>
>>
>> ~/web/emacs $ which grep
>> eshell/grep is a compiled Lisp function in `em-unix.el'
>> ~/web/emacs $ ls | grep lin
>> elisp_link_report.el                        modernization.html
>> elisp_link_report.el~
>> modernization_html_mail.html
>> elisp_link_report.html
>> modernization_meta_key.html
>> elisp_make_link.html                        ms_keyboard
>> emacs_installing_packages.html              wrap-url2.html.gz
>> emacs_manual_problem.html                   xah_emacs_linkify.el
>> emacs_n_unicode.html                        xah_emacs_linkify.el~
>> ~/web/emacs $
>>
>> -----------------------------
>>
>> LOL.
>>
>> Get back to work Len.
>
>
> Why do you think predictable behaviour is nice? ;-)
>
> Ok, you discovered the bug so it is your turn to file a bug report again ...

don't think its a bug. This is eshell not handling redirection correclty
and is something that cannot be easily fixed. Bottom line, don't use
redirection in eshell.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Optimal emacs shell for coding

[Lennart Borgman (gmail)]

Tim X wrote:
>>> ~/web/emacs $ which grep
>>> eshell/grep is a compiled Lisp function in `em-unix.el'
>>> ~/web/emacs $ ls | grep lin
>>> elisp_link_report.el                        modernization.html
>>> elisp_link_report.el~
>>> modernization_html_mail.html
>>> elisp_link_report.html
>>> modernization_meta_key.html
>>> elisp_make_link.html                        ms_keyboard
>>> emacs_installing_packages.html              wrap-url2.html.gz
>>> emacs_manual_problem.html                   xah_emacs_linkify.el
>>> emacs_n_unicode.html                        xah_emacs_linkify.el~
>>> ~/web/emacs $
 >
> don't think its a bug. This is eshell not handling redirection correclty
> and is something that cannot be easily fixed. Bottom line, don't use
> redirection in eshell.


If you look carefully at the output you can see that what is not handled 
is the parameters to "ls". If you try "ls -1" it will work.

So, yes it is a problem with redirection, but only with the (implicit) 
arguments to the first program.

Re: Optimal emacs shell for coding

[Eli Zaretskii]

> Date: Tue, 12 Aug 2008 14:06:02 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: help-gnu-emacs@gnu.org
> 
> If you look carefully at the output you can see that what is not handled 
> is the parameters to "ls". If you try "ls -1" it will work.

What "parameters to ls"?  "ls" was invoked without any parameters.

Re: Optimal emacs shell for coding

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Tue, 12 Aug 2008 14:06:02 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: help-gnu-emacs@gnu.org
>>
>> If you look carefully at the output you can see that what is not handled 
>> is the parameters to "ls". If you try "ls -1" it will work.
> 
> What "parameters to ls"?  "ls" was invoked without any parameters.

If you from a shell do

   ls | grep

then normally ls implicitly gets the -1 parameter (as I understands it), 
but that does not happen currently in eshell.

Re: Optimal emacs shell for coding

[Eli Zaretskii]

> Date: Tue, 12 Aug 2008 20:40:35 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: help-gnu-emacs@gnu.org
> 
> Eli Zaretskii wrote:
> >> Date: Tue, 12 Aug 2008 14:06:02 +0200
> >> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> >> CC: help-gnu-emacs@gnu.org
> >>
> >> If you look carefully at the output you can see that what is not handled 
> >> is the parameters to "ls". If you try "ls -1" it will work.
> > 
> > What "parameters to ls"?  "ls" was invoked without any parameters.
> 
> If you from a shell do
> 
>    ls | grep
> 
> then normally ls implicitly gets the -1 parameter

No, it doesn't.  Please try and see for yourself (I just did).

Re: Optimal emacs shell for coding

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Tue, 12 Aug 2008 20:40:35 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: help-gnu-emacs@gnu.org
>>
>> Eli Zaretskii wrote:
>>>> Date: Tue, 12 Aug 2008 14:06:02 +0200
>>>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>>>> CC: help-gnu-emacs@gnu.org
>>>>
>>>> If you look carefully at the output you can see that what is not handled 
>>>> is the parameters to "ls". If you try "ls -1" it will work.
>>> What "parameters to ls"?  "ls" was invoked without any parameters.
>> If you from a shell do
>>
>>    ls | grep
>>
>> then normally ls implicitly gets the -1 parameter
> 
> No, it doesn't.  Please try and see for yourself (I just did).


We are miscommunicating. Exactly what are you saying?

I am saying that if I from a shell outside of Emacs do

   ls

than I get several files listed on each row while the output from

   ls | grep some-file

implies that ls got the implicit argument -1 when used in the pipe.

Re: Optimal emacs shell for coding

[ken]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 08/12/2008 03:02 PM Lennart Borgman (gmail) wrote:
| Eli Zaretskii wrote:
|>> Date: Tue, 12 Aug 2008 20:40:35 +0200
|>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
|>> CC: help-gnu-emacs@gnu.org
|>>
|>> Eli Zaretskii wrote:
|>>>> Date: Tue, 12 Aug 2008 14:06:02 +0200
|>>>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
|>>>> CC: help-gnu-emacs@gnu.org
|>>>>
|>>>> If you look carefully at the output you can see that what is not
|>>>> handled is the parameters to "ls". If you try "ls -1" it will work.
|>>> What "parameters to ls"?  "ls" was invoked without any parameters.
|>> If you from a shell do
|>>
|>>    ls | grep
|>>
|>> then normally ls implicitly gets the -1 parameter
|>
|> No, it doesn't.  Please try and see for yourself (I just did).
|
|
| We are miscommunicating. Exactly what are you saying?
|
| I am saying that if I from a shell outside of Emacs do
|
|   ls
|
| than I get several files listed on each row while the output from
|
|   ls | grep some-file
|
| implies that ls got the implicit argument -1 when used in the pipe.

Lennart,

You're correct: ls followed by a pipe puts each file on a line by
itself... easily demonstrated by "ls|less", "ls|more", "ls|wc -l",
"ls|grep -E $", and others.

Weird, but true.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFIoeBa8CeNiFrQkecRAu3UAKCONy17ZkSqEpx9Y+mswYDBTmJhSwCfdJgT
ePFlKRA1jfkvRy1/xgSoO8c=
=vgsE
-----END PGP SIGNATURE-----

Re: Optimal emacs shell for coding

[Lennart Borgman (gmail)]

ken wrote:
> | I am saying that if I from a shell outside of Emacs do
> |
> |   ls
> |
> | than I get several files listed on each row while the output from
> |
> |   ls | grep some-file
> |
> | implies that ls got the implicit argument -1 when used in the pipe.
> 
> Lennart,
> 
> You're correct: ls followed by a pipe puts each file on a line by
> itself... easily demonstrated by "ls|less", "ls|more", "ls|wc -l",
> "ls|grep -E $", and others.
> 
> Weird, but true.


That is the magic behind thinking, some people have find that this is 
useful and implemented it ... ;-)

Re: Optimal emacs shell for coding

[Eli Zaretskii]

> Date: Tue, 12 Aug 2008 21:02:21 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: help-gnu-emacs@gnu.org
> 
> Eli Zaretskii wrote:
> >> Date: Tue, 12 Aug 2008 20:40:35 +0200
> >> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> >> CC: help-gnu-emacs@gnu.org
> >>
> >> Eli Zaretskii wrote:
> >>>> Date: Tue, 12 Aug 2008 14:06:02 +0200
> >>>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> >>>> CC: help-gnu-emacs@gnu.org
> >>>>
> >>>> If you look carefully at the output you can see that what is not handled 
> >>>> is the parameters to "ls". If you try "ls -1" it will work.
> >>> What "parameters to ls"?  "ls" was invoked without any parameters.
> >> If you from a shell do
> >>
> >>    ls | grep
> >>
> >> then normally ls implicitly gets the -1 parameter
> > 
> > No, it doesn't.  Please try and see for yourself (I just did).
> 
> 
> We are miscommunicating.

Maybe you are; I am not ;-)

> I am saying that if I from a shell outside of Emacs do
> 
>    ls
> 
> than I get several files listed on each row while the output from
> 
>    ls | grep some-file
> 
> implies that ls got the implicit argument -1 when used in the pipe.

And I'm saying that you are wrong: -1 is not implied in a pipeline
from the shell prompt, either.  Please try that and see for yourself.
I tried that both on GNU/Linux and in a Windows command prompt window,
and GNU `ls' does not imply -1 in either case.

Re: Optimal emacs shell for coding

[Chris F.A. Johnson]

On 2008-08-12, Eli Zaretskii wrote:
...
> And I'm saying that you are wrong: -1 is not implied in a pipeline
> from the shell prompt, either.  Please try that and see for yourself.
> I tried that both on GNU/Linux and in a Windows command prompt window,
> and GNU `ls' does not imply -1 in either case.

    If the output is not going to a terminal, ls will print one file
    per line. This is as required by POSIX and how every version of ls
    behaves.

    At the shell prompt (GNU/Linux, FreeBSD, etc., etc...)

$ touch qwerty uiop asdf ghjkl zxcv bnml
$ ls
asdf  bnml  ghjkl  qwerty  uiop  zxcv
$ ls | cat
asdf
bnml
ghjkl
qwerty
uiop
zxcv


    Emacs eshell behaves incorrectly:

$ ls
asdf  bnml  ghjkl  qwerty  uiop  zxcv
$ ls | cat
asdf  bnml  ghjkl  qwerty  uiop  zxcv


-- 
   Chris F.A. Johnson, webmaster         <http://Woodbine-Gerrard.com>
   ===================================================================
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Re: Optimal emacs shell for coding

[Tim X]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 12 Aug 2008 21:02:21 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: help-gnu-emacs@gnu.org
>> 
>> Eli Zaretskii wrote:
>> >> Date: Tue, 12 Aug 2008 20:40:35 +0200
>> >> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> >> CC: help-gnu-emacs@gnu.org
>> >>
>> >> Eli Zaretskii wrote:
>> >>>> Date: Tue, 12 Aug 2008 14:06:02 +0200
>> >>>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> >>>> CC: help-gnu-emacs@gnu.org
>> >>>>
>> >>>> If you look carefully at the output you can see that what is not handled 
>> >>>> is the parameters to "ls". If you try "ls -1" it will work.
>> >>> What "parameters to ls"?  "ls" was invoked without any parameters.
>> >> If you from a shell do
>> >>
>> >>    ls | grep
>> >>
>> >> then normally ls implicitly gets the -1 parameter
>> > 
>> > No, it doesn't.  Please try and see for yourself (I just did).
>> 
>> 
>> We are miscommunicating.
>
> Maybe you are; I am not ;-)
>
>> I am saying that if I from a shell outside of Emacs do
>> 
>>    ls
>> 
>> than I get several files listed on each row while the output from
>> 
>>    ls | grep some-file
>> 
>> implies that ls got the implicit argument -1 when used in the pipe.
>
> And I'm saying that you are wrong: -1 is not implied in a pipeline
> from the shell prompt, either.  Please try that and see for yourself.
> I tried that both on GNU/Linux and in a Windows command prompt window,
> and GNU `ls' does not imply -1 in either case.
>
Exactly. An you can do another test. Just do 

ls | less

all the files are on one line each. this is standard behavior for ls if
you pipe or redirect it away from a tty. It only formats multi-column
output if the output device is a tty, unless you provide the switch to
force single column output. Note also that usually, the number of
columns is a function of the longest filename and the display width. The
concept of 'width' has no meaning with respect to stdout or when
redirecting via | or > etc.

Note that this is 'normal' behavior - if programs output multiple items
per line, it would screw up programs that you pipe into. 

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Optimal emacs shell for coding

[Thierry Volpiatto]

Tim X <timx@nospam.dev.null> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Tue, 12 Aug 2008 21:02:21 +0200
>>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>>> CC: help-gnu-emacs@gnu.org
>>> 
>>> Eli Zaretskii wrote:
>>> >> Date: Tue, 12 Aug 2008 20:40:35 +0200
>>> >> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>>> >> CC: help-gnu-emacs@gnu.org
>>> >>
>>> >> Eli Zaretskii wrote:
>>> >>>> Date: Tue, 12 Aug 2008 14:06:02 +0200
>>> >>>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>>> >>>> CC: help-gnu-emacs@gnu.org
>>> >>>>
>>> >>>> If you look carefully at the output you can see that what is not handled 
>>> >>>> is the parameters to "ls". If you try "ls -1" it will work.
>>> >>> What "parameters to ls"?  "ls" was invoked without any parameters.
>>> >> If you from a shell do
>>> >>
>>> >>    ls | grep
>>> >>
>>> >> then normally ls implicitly gets the -1 parameter
>>> > 
>>> > No, it doesn't.  Please try and see for yourself (I just did).
>>> 
>>> 
>>> We are miscommunicating.
>>
>> Maybe you are; I am not ;-)
>>
>>> I am saying that if I from a shell outside of Emacs do
>>> 
>>>    ls
>>> 
>>> than I get several files listed on each row while the output from
>>> 
>>>    ls | grep some-file
>>> 
>>> implies that ls got the implicit argument -1 when used in the pipe.
>>
>> And I'm saying that you are wrong: -1 is not implied in a pipeline
>> from the shell prompt, either.  Please try that and see for yourself.
>> I tried that both on GNU/Linux and in a Windows command prompt window,
>> and GNU `ls' does not imply -1 in either case.
>>
> Exactly. An you can do another test. Just do 
>
> ls | less
>
> all the files are on one line each. this is standard behavior for ls if
> you pipe or redirect it away from a tty. It only formats multi-column
> output if the output device is a tty, unless you provide the switch to
> force single column output. Note also that usually, the number of
> columns is a function of the longest filename and the display width. The
> concept of 'width' has no meaning with respect to stdout or when
> redirecting via | or > etc.
>
> Note that this is 'normal' behavior - if programs output multiple items
> per line, it would screw up programs that you pipe into. 
>
> Tim
Sorry, i insert again this reply here, i think i did a mistake and reply
on another topic.

As Lennart said you call ls with -1 arg or you can always call ls with
this arg setting it like that:

,----
| (setq eshell-ls-initial-args '(-1)) 
`----

now when you call for example "ls | wc -l" , you will have the
good number of lines.

It would be cool to have a function to call in some hook to call ls -1
only if there is a "|" after ls, this function do that but i need a hook
to call it:

,----
| (defun eshell-set-ls ()
|   (let ((com-line
|          (eshell-parse-arguments (re-search-backward "ls") (line-end-position))))
|     (if (equal (nth 1 com-line) '(eshell-operator "|"))
|         (setq eshell-ls-initial-args '(-1))
|         (setq eshell-ls-initial-args nil))))
`----


-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

eshell pipelines (Was: Re: Optimal emacs shell for coding)

[David Hansen]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]


[For emacs-devel: 

In gnu.emacs.help there is a discussion about some little eshell,
eshell/ls bug.  Processes in a pipeline get a TTY for IO (via
`start-process').  Quite some programs behave different whether they
have a TTY or not. 

The other thing is that eshell/ls does not output one file per line
when in a pipeline (as the usual GNU ls does).]

On Wed, 13 Aug 2008 13:21:00 +0200 Thierry Volpiatto wrote:

> As Lennart said you call ls with -1 arg or you can always call ls with
> this arg setting it like that:
>
> ,----
> | (setq eshell-ls-initial-args '(-1)) 
> `----
>
> now when you call for example "ls | wc -l" , you will have the
> good number of lines.
>
> It would be cool to have a function to call in some hook to call ls -1
> only if there is a "|" after ls, this function do that but i need a hook
> to call it:
>
> ,----
> | (defun eshell-set-ls ()
> |   (let ((com-line
> |          (eshell-parse-arguments (re-search-backward "ls") (line-end-position))))
> |     (if (equal (nth 1 com-line) '(eshell-operator "|"))
> |         (setq eshell-ls-initial-args '(-1))
> |         (setq eshell-ls-initial-args nil))))
> `----

Try the attached patch.  It

 * Starts subprocesses in a (eshell) pipeline using a pipe and not a TTY
   (this should also give some performance boost).

 * Appends "-1" to eshell/ls if ls is called in a pipeline.

At the time it's feature freeze for Emacs so it will probably take some
time to make it in there.  Cc: anyways, maybe some old timer can approve
the two lines.


David


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1676 bytes --]

*** em-ls.el.~1.33.~	2008-06-07 20:14:50.000000000 +0200
--- em-ls.el	2008-08-13 14:05:43.000000000 +0200
***************
*** 299,304 ****
--- 299,306 ----
    (let ((insert-func 'eshell-buffered-print)
  	(error-func 'eshell-error)
  	(flush-func 'eshell-flush))
+     ;; In pipelines use the -1 switch.
+     (and eshell-in-pipeline-p (push "-1" args))
      (eshell-do-ls args)))
  
  (put 'eshell/ls 'eshell-no-numeric-conversions t)
*** esh-proc.el.~1.21.~	2008-05-12 20:30:41.000000000 +0200
--- esh-proc.el	2008-08-13 14:20:38.000000000 +0200
***************
*** 249,260 ****
  	 proc decoding encoding changed)
      (cond
       ((fboundp 'start-process)
!       (setq proc
! 	    (apply 'start-process
! 		   (file-name-nondirectory command) nil
! 		   ;; `start-process' can't deal with relative
! 		   ;; filenames
! 		   (append (list (expand-file-name command)) args)))
        (eshell-record-process-object proc)
        (set-process-buffer proc (current-buffer))
        (if (eshell-interactive-output-p)
--- 249,262 ----
  	 proc decoding encoding changed)
      (cond
       ((fboundp 'start-process)
!       ;; Don't use a TTY for processes in a pipeline.
!       (let ((process-connection-type (not eshell-in-pipeline-p)))
!         (setq proc
!               (apply 'start-process
!                      (file-name-nondirectory command) nil
!                      ;; `start-process' can't deal with relative
!                      ;; filenames
!                      (append (list (expand-file-name command)) args))))
        (eshell-record-process-object proc)
        (set-process-buffer proc (current-buffer))
        (if (eshell-interactive-output-p)

Re: eshell pipelines

[Thierry Volpiatto]

David Hansen <david.hansen@gmx.net> writes:

> [For emacs-devel: 
>
> In gnu.emacs.help there is a discussion about some little eshell,
> eshell/ls bug.  Processes in a pipeline get a TTY for IO (via
> `start-process').  Quite some programs behave different whether they
> have a TTY or not. 
>
> The other thing is that eshell/ls does not output one file per line
> when in a pipeline (as the usual GNU ls does).]
>
> On Wed, 13 Aug 2008 13:21:00 +0200 Thierry Volpiatto wrote:
>
>> As Lennart said you call ls with -1 arg or you can always call ls with
>> this arg setting it like that:
>>
>> ,----
>> | (setq eshell-ls-initial-args '(-1)) 
>> `----
>>
>> now when you call for example "ls | wc -l" , you will have the
>> good number of lines.
>>
>> It would be cool to have a function to call in some hook to call ls -1
>> only if there is a "|" after ls, this function do that but i need a hook
>> to call it:
>>
>> ,----
>> | (defun eshell-set-ls ()
>> |   (let ((com-line
>> |          (eshell-parse-arguments (re-search-backward "ls") (line-end-position))))
>> |     (if (equal (nth 1 com-line) '(eshell-operator "|"))
>> |         (setq eshell-ls-initial-args '(-1))
>> |         (setq eshell-ls-initial-args nil))))
>> `----
>
> Try the attached patch.  It
>
>  * Starts subprocesses in a (eshell) pipeline using a pipe and not a TTY
>    (this should also give some performance boost).
>
>  * Appends "-1" to eshell/ls if ls is called in a pipeline.
>
> At the time it's feature freeze for Emacs so it will probably take some
> time to make it in there.  Cc: anyways, maybe some old timer can approve
> the two lines.

After some quick tests that work fine.
Thank you.

>
> *** em-ls.el.~1.33.~	2008-06-07 20:14:50.000000000 +0200
> --- em-ls.el	2008-08-13 14:05:43.000000000 +0200
> ***************
> *** 299,304 ****
> --- 299,306 ----
>     (let ((insert-func 'eshell-buffered-print)
>   	(error-func 'eshell-error)
>   	(flush-func 'eshell-flush))
> +     ;; In pipelines use the -1 switch.
> +     (and eshell-in-pipeline-p (push "-1" args))
>       (eshell-do-ls args)))
>   
>   (put 'eshell/ls 'eshell-no-numeric-conversions t)
> *** esh-proc.el.~1.21.~	2008-05-12 20:30:41.000000000 +0200
> --- esh-proc.el	2008-08-13 14:20:38.000000000 +0200
> ***************
> *** 249,260 ****
>   	 proc decoding encoding changed)
>       (cond
>        ((fboundp 'start-process)
> !       (setq proc
> ! 	    (apply 'start-process
> ! 		   (file-name-nondirectory command) nil
> ! 		   ;; `start-process' can't deal with relative
> ! 		   ;; filenames
> ! 		   (append (list (expand-file-name command)) args)))
>         (eshell-record-process-object proc)
>         (set-process-buffer proc (current-buffer))
>         (if (eshell-interactive-output-p)
> --- 249,262 ----
>   	 proc decoding encoding changed)
>       (cond
>        ((fboundp 'start-process)
> !       ;; Don't use a TTY for processes in a pipeline.
> !       (let ((process-connection-type (not eshell-in-pipeline-p)))
> !         (setq proc
> !               (apply 'start-process
> !                      (file-name-nondirectory command) nil
> !                      ;; `start-process' can't deal with relative
> !                      ;; filenames
> !                      (append (list (expand-file-name command)) args))))
>         (eshell-record-process-object proc)
>         (set-process-buffer proc (current-buffer))
>         (if (eshell-interactive-output-p)

-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

Re: eshell pipelines

[Glenn Morris]

David Hansen wrote:

> [For emacs-devel: 
>
> In gnu.emacs.help there is a discussion about some little eshell,
> eshell/ls bug. 

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=699

(now on three separate mailing lists...)

Re: eshell pipelines

[David Hansen]

On Wed, 13 Aug 2008 12:09:07 -0400 Glenn Morris wrote:

> David Hansen wrote:
>
>> [For emacs-devel: 
>>
>> In gnu.emacs.help there is a discussion about some little eshell,
>> eshell/ls bug. 
>
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=699
>
> (now on three separate mailing lists...)

I find gmane.emacs.bug incredible "hard" to read.  Threads seem to
randomly stop and start again (w/o gnus finding the parents) and purely
administrative messages pop up every now and then.

Back to the topic:  not giving the pipelined processes a TTY will
prevent similar problems w/ non eshell builtins.  And in most cases it
should be faster as well, e.g. GNU libc uses line buffering on a TTY.

But probably we should first find a way to disable this for the last
command in the pipeline.  This is already done in
`eshell-do-pipelines-synchronously' (do we really need compat code for
Emacsen w/o `start-process'?).  I'll try to figure out how to do it
right.

David

Re: Optimal emacs shell for coding

[Eli Zaretskii]

> From: Tim X <timx@nospam.dev.null>
> Date: Tue, 12 Aug 2008 18:06:59 +1000
> 
> >> ~/web/emacs $ which grep
> >> eshell/grep is a compiled Lisp function in `em-unix.el'
> >> ~/web/emacs $ ls | grep lin
> >> elisp_link_report.el                        modernization.html
> >> elisp_link_report.el~
> >> modernization_html_mail.html
> >> elisp_link_report.html
> >> modernization_meta_key.html
> >> elisp_make_link.html                        ms_keyboard
> >> emacs_installing_packages.html              wrap-url2.html.gz
> >> emacs_manual_problem.html                   xah_emacs_linkify.el
> >> emacs_n_unicode.html                        xah_emacs_linkify.el~
> >> ~/web/emacs $
> >>
> >> -----------------------------
> >>
> >> LOL.
> >>
> >> Get back to work Len.
> >
> >
> > Why do you think predictable behaviour is nice? ;-)
> >
> > Ok, you discovered the bug so it is your turn to file a bug report again ...
> 
> don't think its a bug. This is eshell not handling redirection correclty
> and is something that cannot be easily fixed. Bottom line, don't use
> redirection in eshell.

FWIW, I don't see anything wrong with the above: just unwrap the
obviously wrapped lines, and you will see that everything is
honky-dory.

Re: Optimal emacs shell for coding

[David Hansen]

On Tue, 12 Aug 2008 21:30:55 +0300 Eli Zaretskii wrote:

>> From: Tim X <timx@nospam.dev.null>
>> Date: Tue, 12 Aug 2008 18:06:59 +1000
>> 
>> >> ~/web/emacs $ which grep
>> >> eshell/grep is a compiled Lisp function in `em-unix.el'
>> >> ~/web/emacs $ ls | grep lin
>> >> elisp_link_report.el                        modernization.html
>> >> elisp_link_report.el~
>> >> modernization_html_mail.html
>> >> elisp_link_report.html
>> >> modernization_meta_key.html
>> >> elisp_make_link.html                        ms_keyboard
>> >> emacs_installing_packages.html              wrap-url2.html.gz
>> >> emacs_manual_problem.html                   xah_emacs_linkify.el
>> >> emacs_n_unicode.html                        xah_emacs_linkify.el~
>> >> ~/web/emacs $
>> >>
>> >> -----------------------------
>> >>
>> >> LOL.
>> >>
>> >> Get back to work Len.
>> >
>> >
>> > Why do you think predictable behaviour is nice? ;-)
>> >
>> > Ok, you discovered the bug so it is your turn to file a bug report again ...
>> 
>> don't think its a bug. This is eshell not handling redirection correclty
>> and is something that cannot be easily fixed. Bottom line, don't use
>> redirection in eshell.
>
> FWIW, I don't see anything wrong with the above: just unwrap the
> obviously wrapped lines, and you will see that everything is
> honky-dory.

But it's different from how bash + ls behave in a "normal" terminal.
When stdout for the `ls' command is not a tty it prints one file per
line (IMHO the right way).

David

Re: Optimal emacs shell for coding

[Rupert Swarbrick]

[-- Attachment #1.1: Type: text/plain, Size: 965 bytes --]


>>> 
>>> >> ~/web/emacs $ which grep
...
>>> >> emacs_n_unicode.html                        xah_emacs_linkify.el~
>>> >> ~/web/emacs $
...
>>> >
>>> >
>>> > Why do you think predictable behaviour is nice? ;-)
>>> >
>>> > Ok, you discovered the bug so it is your turn to file a bug report again ...
>>> 
>>> don't think its a bug. This is eshell not handling redirection correclty
>>> and is something that cannot be easily fixed. Bottom line, don't use
>>> redirection in eshell.
>>
>> FWIW, I don't see anything wrong with the above: just unwrap the
>> obviously wrapped lines, and you will see that everything is
>> honky-dory.
>
> But it's different from how bash + ls behave in a "normal" terminal.
> When stdout for the `ls' command is not a tty it prints one file per
> line (IMHO the right way).
>
> David

Well, I just dug out coreutils' sources. In ls.c, line 1423 in the
function decode_switches, the magic reveals itself:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: Type: text/x-c++src, Size: 688 bytes --]

  switch (ls_mode)
    {
    case LS_MULTI_COL:
      /* This is for the `dir' program.  */
      format = many_per_line;
      set_quoting_style (NULL, escape_quoting_style);
      break;

    case LS_LONG_FORMAT:
      /* This is for the `vdir' program.  */
      format = long_format;
      set_quoting_style (NULL, escape_quoting_style);
      break;

    case LS_LS:
      /* This is for the `ls' program.  */
      if (isatty (STDOUT_FILENO))
	{
	  format = many_per_line;
	  /* See description of qmark_funny_chars, above.  */
	  qmark_funny_chars = true;
	}
      else
	{
	  format = one_per_line;
	  qmark_funny_chars = false;
	}
      break;

    default:
      abort ();
    }

[-- Attachment #1.3: Type: text/plain, Size: 170 bytes --]


(If my gnus-foo worked, otherwise I'll post the snippet in a sec)

Presumably, isatty(STDOUT_FILENO) is returning true for some reason when
called under eshell?

Rupert

[-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --]

Re: Optimal emacs shell for coding

[Eli Zaretskii]

> From: Xah <xahlee@gmail.com>
> Date: Mon, 11 Aug 2008 06:30:02 -0700 (PDT)
> 
> Run eshell if you are in Windows and don't have cygwin installed and
> want to run unix commands such as ls, cd, mkdir, etc.

Actually, Cygwin is not the only Unixy shell in town, and ls does not
need a Unixy shell to be run on Windows, to say nothing of cd and
mkdir.  So to be useful _and_ correct, this should be rephrased as

  Rin Eshell if you are on Windows and don't have a Unixy shell
  (sh.exe) installed.

Of course, Eshell is much more than just a Unixy shell emulation, so
even the above is misleading...

Re: Optimal emacs shell for coding

[Tim X]

Xah <xahlee@gmail.com> writes:

> On Aug 11, 4:38 am, Jonathan Groll <li...@groll.co.za> wrote:
>> I know of only three ways to get an emacs shell:
>>
>> M-x terminal-emulator
>> M-x shell
>> M-x eshell
>> (There is also M-x shell-command RET)
>>
>> Question is, which one is best for coding? Lately I've found myself
>> opening up an xterm session to do miscellaneous coding support tasks -
>> and am mostly struggling with different readline history keybindings
>> (eg. I'm used to entering C-r at a shell to get (reverse-i-search) -
>> obviously in an emacs shell this will have a dfferent outcome to what
>> I desire!
>>

It depends on what you want to do. If I'm writing shell scripts, I will
open an emacs buffer to put the script in and then run the script in
whichever other shell is most appropriate (depending on things such as
whether I plan to use redirection (don't use eshell), run with little
interaction (probably just use run-shell) or if I require ansi, ncurses or
other screen/terminal support, M-x term. 

>> Any recommendations?
>
> They really all have different purposs.
>
>
> • M-x shell-command
> lets you run a single shell cammand.
>
> • M-x shell
> command line interface to OS.
>
> • M-x terminal-emulator
>
> This is actually a terminal emulator.
> For example, you can start a telnet or ssh or top in it.
> You can also start a vi, or even emacs itself within.
>
> You cannot run these problems with M-x shell, for example.
>
> • M-x eshell
> This is just like shell, except it's written in elisp.
> The purpose is so that you can have access to the familiar unix shell
> in different OSes such as MS Windows.
>
> In general, the shell-command and shell is most useful. Run eshell if
> you are in Windows and don't have cygwin installed and want to run
> unix commands such as ls, cd, mkdir, etc. If you need to run telnet,
> ssh, top, or any program that fills a screen, you'll need to run term.
> I don't particular recommend it because once in term, many default
> keybindings of emacs won't work because it pretends to be a term emu.
> If you want to run ssh etc, best to start in a real term emulator.

M-x term does re-define some key sequences so that they don't conflict
with, in particular, shell control sequences such as Ctrl C. However, yu
also have line mode and character mode, which enables you to switch from
keyboard input being sent as characters to the command line to being
able to move around in the buffer and do things like cut and paste etc,
which you can then use in another buffer. 

Eshell can cause confusion because it cannot handle redirection
correctly. This can give some unexpected results and you don't
necessarily get any eror message warning you. I once ran a simple shell
script that grabbed some xml using wget and then displayed it on the
screen. When I ran it under eshell, I thought the service I was trying
to access was not working because nothing was being displayed to the
screen. I then realised that the data was being returned, but eshell
wasn't handling the redirection to stdout correctly. However, if you
keep this in mind, eshell is very useful and you can execute emacs lisp
directly from the command line, plus all the key-bindings are as you
wold expect them to be. 

Note also that with reference to running programs like telnet, rlogin
ssh and top, there are facilities available to do this from within
emacs. Emacs has M-x telnet, M-x rlogin and there are at least two
ssh.el packages out there. You can also set the rlogin-program variable
to use ssh rather than rlogini. For top, their is view-process.el (quite
old) and in the CVS version of emacs proced, which is like a top for
emacs.

and of course, there is tramp, which can allow you to edit files and run
remote processes from inside emacs. 

to provide more specific help on what would be most useful, we would
need more details regarding what it is you want to do and what platform
your running on.

HTH

Tim

-- 
tcross (at) rapttech dot com dot au

M-x terminal-emulator vs M-x term (was: Re: Optimal emacs shell for coding)

[Jonathan Groll]

On Tue, Aug 12, 2008 at 06:02:48PM +1000, Tim X wrote:
<snip>
> It depends on what you want to do. If I'm writing shell scripts, I will
> open an emacs buffer to put the script in and then run the script in
> whichever other shell is most appropriate (depending on things such as
> whether I plan to use redirection (don't use eshell), run with little
> interaction (probably just use run-shell) or if I require ansi, ncurses or
> other screen/terminal support, M-x term. 
> 

One thing that is difficult to understand is the difference between
M-x term     and
M-x terminal-emulator

The former behaves as is described in the Emacs manual for the node
"Term mode", namely the C-c escape sequence is respected, there is
both a char and a line mode, and a feature that I like, in char mode,
is that the arrow keys work for browsing the shell history (under
bash).

However, launching a terminal emulator with M-x terminal-emulator
results in completely different behaviour. The escape sequence is
C-^. There does not seem to be a line mode? In adddition, in
terminal-emulator the arrow keys are not bound - "Function key up>'
ignored" and other messages appear if these keys are pressed.

Is there a relationship between term and terminal-emulator (as the
Emacs manual seems to imply?), and are there any known programs that
work better in terminal-emulator than in term? 

Cheers,
Jonathan.

Re: Optimal emacs shell for coding

[Mike Treseler]

Jonathan Groll wrote:
> I know of only three ways to get an emacs shell:
> M-x terminal-emulator
> M-x shell                                                                                                    
> M-x eshell                  
> (There is also M-x shell-command RET)
...
> Any recommendations?
> 
> Many thanks,
> Jonathan Groll.
> 

I use M-x shell for vhdl simulation/debug sessions.
I like having both unix history
*and* emacs search/editing of the old commands.
Sometimes I use a little xterm on the side.

   -- Mike Treseler

Re: Optimal emacs shell for coding

[weber]

On Aug 11, 10:40 am, Mike Treseler <mtrese...@gmail.com> wrote:
> Jonathan Groll wrote:
> > I know of only three ways to get an emacs shell:
> > M-x terminal-emulator
> > M-x shell                                                                                                    
> > M-x eshell                  
> > (There is also M-x shell-command RET)
> ...
> > Any recommendations?
>
> > Many thanks,
> > Jonathan Groll.
>
> I use M-x shell for vhdl simulation/debug sessions.
> I like having both unix history
> *and* emacs search/editing of the old commands.
> Sometimes I use a little xterm on the side.
>
>    -- Mike Treseler

Do you have any personal functions for working with vhdl and/or vhdl
simulation/synthesis tools?
Curiosly,
weber

Re: Optimal emacs shell for coding

[Mike Treseler]

weber wrote:

> Do you have any personal functions for working with vhdl and/or vhdl
> simulation/synthesis tools?

vhdl-mode covers design entry and simulation make very well.
I copy/paste vsim commands from my code comments to M-x shell.
My special sauce for synthesis is here:
http://mysite.verizon.net/miketreseler/
I may make vhdl-mode templates someday.

     -- Mike Treseler

Optimal emacs shell for coding

[Jonathan Groll]

I know of only three ways to get an emacs shell:

M-x terminal-emulator
M-x shell                                                                                                    
M-x eshell                  
(There is also M-x shell-command RET)
         
Question is, which one is best for coding? Lately I've found myself
opening up an xterm session to do miscellaneous coding support tasks -
and am mostly struggling with different readline history keybindings
(eg. I'm used to entering C-r at a shell to get (reverse-i-search) -
obviously in an emacs shell this will have a dfferent outcome to what
I desire!

Any recommendations?

Many thanks,
Jonathan Groll.

Re: Optimal emacs shell for coding

[Peter Dyballa]

Am 11.08.2008 um 13:38 schrieb Jonathan Groll:

> Question is, which one is best for coding?


Bigger question is: what do you mean with "coding?"


For coding, i.e., writing code to be compiled, interpreted, or  
executed, you don't need a shell. Even vi could be OK for this  
purpose ...

--
Greetings

   Pete

Time is an illusion. Lunchtime, doubly so.

Re: Optimal emacs shell for coding

[Thien-Thi Nguyen]

() Jonathan Groll <lists@groll.co.za>
() Mon, 11 Aug 2008 13:38:54 +0200

   Any recommendations?

I consider Emacs the optimal shell.
Some keybindings i find especially useful:

 (global-set-key "\M-m" 'compile)
 (define-key minibuffer-local-map "\M-m" 'exit-minibuffer)

Left thumb on meta, and `m', `p', `n' (as needed)
and finally `m' w/ the right hand.

thi