Mysterious hidden end of line characters.

Mysterious hidden end of line characters.

[David]

I have a strange problem with invisible end of line characters.

Yesterday I was trying to configure GRASS6.3 using the following
single line of code.


CFLAGS=-O2 ./configure \
	 --with-gdal=/usr/bin/gdal-config \
	 --with-tcltk \
	 --with-tcltk-includes=/usr/include/tcl8.4 \
	 --x-includes=/usr/include/X11 \
	--with-postgres-includes=/usr/include/postgresql \
	--with-freetype-includes=/usr/include/freetype2 \
	--x-includes=/usr/include/X11 \
	--x-libraries=/usr/lib/X11 \
	--with-libs=/usr/lib64 \
	--with-blas \
	--with-mysql \
	--with-mysql-includes=/usr/include/mysql \
	--with-cxx \
	--with-freetype \
	--with-freetype-includes=/usr/include/freetype2 \
	--with-readline \
	--with-sqlite \
	--with-tiff \
	--with-x \
	 --with-odbc \
	--enable-64bit \
	2>&1 | tee config_log.txt


Normally the \ character tells the shell not to execute the line but
to wait for the next line and execture them as one, so everything
above is seen by the computer as a single line. Right?

Well, not on my computer.  Each time I copied the lines from emacs to
a terminal (konsole) for some reason the \ was being over riden and
the terminal tried executing the code one line at a time. My effort to
configure GRASS failled until I removed every \ and collapsed
everything down to the following single line.

CFLAGS=-O2 ./configure --with-gdal=/usr/bin/gdal-config --with-tcltk --with-tcltk-includes=/usr/include/tcl8.4 --x-includes=/usr/include/X11 --with-postgres-includes=/usr/include/postgresql --with-freetype-includes=/usr/include/freetype2 --x-includes=/usr/include/X11 --x-libraries=/usr/lib/X11 --with-libs=/usr/lib64 --with-blas --with-mysql --with-mysql-includes=/usr/include/mysql --with-cxx --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-readline --with-sqlite --with-tiff --with-x --with-odbc --enable-64bit 2>&1 | tee config_log.txt

A colleage then complained to me saying I had some kind of invisible
character at the end of each line of a shell script (naturally, writen
in emacs) that I'd sent him. He was having to guess where each of
these nasty characters was and delete them line by line.  I think he
has emacs on Ubuntu, I am running emacs21 on Debian etch.

How might I try to identify what is going on here?

cheers
Dave

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

Did you try running delete-trailing-white-space or picture-mode on your
files ?

David <dpleydel@univ-fcomte.fr> writes:

> I have a strange problem with invisible end of line characters.
>
> Yesterday I was trying to configure GRASS6.3 using the following
> single line of code.
>
>
> CFLAGS=-O2 ./configure \
> 	 --with-gdal=/usr/bin/gdal-config \
> 	 --with-tcltk \
> 	 --with-tcltk-includes=/usr/include/tcl8.4 \
> 	 --x-includes=/usr/include/X11 \
> 	--with-postgres-includes=/usr/include/postgresql \
> 	--with-freetype-includes=/usr/include/freetype2 \
> 	--x-includes=/usr/include/X11 \
> 	--x-libraries=/usr/lib/X11 \
> 	--with-libs=/usr/lib64 \
> 	--with-blas \
> 	--with-mysql \
> 	--with-mysql-includes=/usr/include/mysql \
> 	--with-cxx \
> 	--with-freetype \
> 	--with-freetype-includes=/usr/include/freetype2 \
> 	--with-readline \
> 	--with-sqlite \
> 	--with-tiff \
> 	--with-x \
> 	 --with-odbc \
> 	--enable-64bit \
> 	2>&1 | tee config_log.txt
>
>
> Normally the \ character tells the shell not to execute the line but
> to wait for the next line and execture them as one, so everything
> above is seen by the computer as a single line. Right?
>
> Well, not on my computer.  Each time I copied the lines from emacs to
> a terminal (konsole) for some reason the \ was being over riden and
> the terminal tried executing the code one line at a time. My effort to
> configure GRASS failled until I removed every \ and collapsed
> everything down to the following single line.
>
> CFLAGS=-O2 ./configure --with-gdal=/usr/bin/gdal-config --with-tcltk --with-tcltk-includes=/usr/include/tcl8.4 --x-includes=/usr/include/X11 --with-postgres-includes=/usr/include/postgresql --with-freetype-includes=/usr/include/freetype2 --x-includes=/usr/include/X11 --x-libraries=/usr/lib/X11 --with-libs=/usr/lib64 --with-blas --with-mysql --with-mysql-includes=/usr/include/mysql --with-cxx --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-readline --with-sqlite --with-tiff --with-x --with-odbc --enable-64bit 2>&1 | tee config_log.txt
>
> A colleage then complained to me saying I had some kind of invisible
> character at the end of each line of a shell script (naturally, writen
> in emacs) that I'd sent him. He was having to guess where each of
> these nasty characters was and delete them line by line.  I think he
> has emacs on Ubuntu, I am running emacs21 on Debian etch.
>
> How might I try to identify what is going on here?
>
> cheers
> Dave
>
>
> _______________________________________________
> help-gnu-emacs mailing list
> help-gnu-emacs@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
>

-- 
A + Thierry
Pub key: http://pgp.mit.edu

Re: Mysterious hidden end of line characters.

[David]

On Sat, Jan 26, 2008 at 08:21:24PM +0100, Thierry Volpiatto wrote:
> Did you try running delete-trailing-white-space or picture-mode on your
> files ?
> 

Thanks for the suggestion, but that didn't seem to do the job.

Re: Mysterious hidden end of line characters.

[David]

On Sat, Jan 26, 2008 at 08:21:24PM +0100, Thierry Volpiatto wrote:
> Did you try running delete-trailing-white-space or picture-mode on your
> files ?

Hey hold on, my last post was wrong, the delete-trailing-white-space
function solves the problem of pasting multiple lines into the
shell. Awesome, nice one dude.

I'll have to ask my colleage if he still has problems with the scripts
I send him after I use this funciton.

Thanks for the solution Thierry, this turned out to be way simpler
than I feared.

Dave :0)

Re: Mysterious hidden end of line characters.

[David]

> Hey hold on, my last post was wrong, the delete-trailing-white-space
> function solves the problem of pasting multiple lines into the
> shell. Awesome, nice one dude.
> 

Looks like nobody received the last post anyway. Again many thanks.

Dave

Re: Mysterious hidden end of line characters.

[Tim X]

David <dpleydel@univ-fcomte.fr> writes:

> On Sat, Jan 26, 2008 at 08:21:24PM +0100, Thierry Volpiatto wrote:
>> Did you try running delete-trailing-white-space or picture-mode on your
>> files ?
>
> Hey hold on, my last post was wrong, the delete-trailing-white-space
> function solves the problem of pasting multiple lines into the
> shell. Awesome, nice one dude.
>
> I'll have to ask my colleage if he still has problems with the scripts
> I send him after I use this funciton.
>
> Thanks for the solution Thierry, this turned out to be way simpler
> than I feared.
>

Its good you have a solution, but you have only addressed the symptom
and not the cause. this may be good enough, but I'd suggest that as this
shouldn't happen, there is something else wrong and its likely to cause
you subtle problems in other areas. 

What does emacs show on the mode line? For example, I have a u: at the
left to indicate my script buffer is in UTF-8 as this is the default
locale on my Debian system.

What is the default locale setting on your Debian system and that of
your colleagues?

What major and minor modes do you have loaded? 

Do you get the same 'odd' cut and paste behavior with all terminals
(i.e. gnome-terminal, xterm, rxvt and the linux console)? Are you using
anything like CUA mode? If you open a buffer with VI in a terminal and
paste from emacs into that buffer, do you get odd behavior, such as the
text 'stepping'?

Tim

-- 
tcross (at) rapttech dot com dot au

kgdb in emacs

[Sanjeev Kumar.S]

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

Hi, 
     I'm trying to use kgdb in emacs on Freebsd V6.2. I'm able to use kgdb 
     on the command line like this 
     kgdb -r /dev/cuad0 kernel.debug.
     In 6.2 there is no gdb -k, only kgdb.

     But when I run it in emacs. M-x gdb
     Run gdb ( like this ) : kgdb -r /dev/cuad0 kernel.debug
     I get :
     Current directory is /dev/
     kgdb: multiple core files specified. Ignored
     kgdb: d: No such file or directory.
     Debugger exited abnormally with code 1

     Why is emacs even interpretting my commands.
     Why doesn't it just call kgdb with whatever arguments
     I give ? 

Regards,
Sanjeev.
     
     

       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

[-- Attachment #1.2: Type: text/html, Size: 1240 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: kgdb in emacs

[Nick Roberts]

 >      I'm trying to use kgdb in emacs on Freebsd V6.2. I'm able to use kgdb 
 >      on the command line like this 
 >      kgdb -r /dev/cuad0 kernel.debug.
 >      In 6.2 there is no gdb -k, only kgdb.

When can you use gdb -k?

With the latest GDB from CVS, I get:

$ gdb -k
gdb: unrecognized option `-k'

 >      But when I run it in emacs. M-x gdb
 >      Run gdb ( like this ) : kgdb -r /dev/cuad0 kernel.debug
 >      I get :
 >      Current directory is /dev/
 >      kgdb: multiple core files specified. Ignored
 >      kgdb: d: No such file or directory.
 >      Debugger exited abnormally with code 1
 > 
 >      Why is emacs even interpretting my commands.
 >      Why doesn't it just call kgdb with whatever arguments
 >      I give ? 

For some debuggers Emacs adds extra arguments.  It's also trying to parse the
name of the executable from the command line for the mode-line and hasn't been
designed with kgdb in mind.

I've not used kgdb and you don't say what version of Emacs you are using, but I
know kgdb can work in Emacs (and with Freebsd) because I've seen this
screenshot:

http://people.freebsd.org/~simokawa/gdb/dcons-emacs-gud.PNG

and this description:

http://wiki.freebsd.org/DebugWithDcons

where Hidetoshi Shimokawa sets gud-gdba-command-name

(setq gud-gdba-command-name "kgdb -a -a -a -r :12345")
  
It looks like "-a -a -a" sets the annotation level to 3 as needed by the
Graphical Interface (Emacs 22 only).  Text mode (or Emacs 21 or earlier)
presumably works with just "-a".


 >      Current directory is /dev/

It thinks the executable is /dev/cuad0, being the first argument that doesn't
start with a hyphen.

 >      kgdb: multiple core files specified. Ignored
 >      kgdb: d: No such file or directory.

I don't know what has happened here because this seems to parse correctly

 >      Debugger exited abnormally with code 1


Assuming kgdb is a bit like gdb with a remote target, does:

  Run gdb ( like this ) : kgdb -a -a -a kernel.debug
  (kgdb) target remote  /dev/cuad0

work?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: kgdb in emacs

[Sanjeev Kumar.S]

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

Thank you very much Nick, Your clue of emacs version prompted me
to upgrade my emacs. after which I'm able to do it.
BTW,  my earlier emacs version was 21.2.4 and now it is 22.0.50.1

One more question: I'm still not able to open the file another emacs
window. I thought this was supposed happen automatically. In other
instances of emacs ( like when debugging apps ) the source code file
opens automatically in another emacs window ( vertical split style).
Even if it doesn't, when I enter "f" it opens up automatically.

One possibility is, though i changed the emacs current directory
to /usr/obj/usr/src/sys/MYKERNEL/ , the -r /dev/cuad0 option would have
changed the default directory, as evident in the file line when a gud
window is opened:
Current directory is /dev/
:(

I tried changing the current directory again to .../MYKERNEL/ but still
"f" doesn't open the source in another window ?

Any suggestions ?

Thanks again & Regards,
Sanjeev.

Nick Roberts <nickrob@snap.net.nz> wrote:  >      I'm trying to use kgdb in emacs on Freebsd V6.2. I'm able to use kgdb 
 >      on the command line like this 
 >      kgdb -r /dev/cuad0 kernel.debug.
 >      In 6.2 there is no gdb -k, only kgdb.

When can you use gdb -k?

With the latest GDB from CVS, I get:

$ gdb -k
gdb: unrecognized option `-k'

 >      But when I run it in emacs. M-x gdb
 >      Run gdb ( like this ) : kgdb -r /dev/cuad0 kernel.debug
 >      I get :
 >      Current directory is /dev/
 >      kgdb: multiple core files specified. Ignored
 >      kgdb: d: No such file or directory.
 >      Debugger exited abnormally with code 1
 > 
 >      Why is emacs even interpretting my commands.
 >      Why doesn't it just call kgdb with whatever arguments
 >      I give ? 

For some debuggers Emacs adds extra arguments.  It's also trying to parse the
name of the executable from the command line for the mode-line and hasn't been
designed with kgdb in mind.

I've not used kgdb and you don't say what version of Emacs you are using, but I
know kgdb can work in Emacs (and with Freebsd) because I've seen this
screenshot:

http://people.freebsd.org/~simokawa/gdb/dcons-emacs-gud.PNG

and this description:

http://wiki.freebsd.org/DebugWithDcons

where Hidetoshi Shimokawa sets gud-gdba-command-name

(setq gud-gdba-command-name "kgdb -a -a -a -r :12345")
  
It looks like "-a -a -a" sets the annotation level to 3 as needed by the
Graphical Interface (Emacs 22 only).  Text mode (or Emacs 21 or earlier)
presumably works with just "-a".


 >      Current directory is /dev/

It thinks the executable is /dev/cuad0, being the first argument that doesn't
start with a hyphen.

 >      kgdb: multiple core files specified. Ignored
 >      kgdb: d: No such file or directory.

I don't know what has happened here because this seems to parse correctly

 >      Debugger exited abnormally with code 1


Assuming kgdb is a bit like gdb with a remote target, does:

  Run gdb ( like this ) : kgdb -a -a -a kernel.debug
  (kgdb) target remote  /dev/cuad0

work?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

[-- Attachment #1.2: Type: text/html, Size: 3831 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: kgdb in emacs

[Nick Roberts]

 > Thank you very much Nick, Your clue of emacs version prompted me
 > to upgrade my emacs. after which I'm able to do it.

I guess you mean Emacs now parses your command line now.

But presumably you still get *gud-cuad0* in the mode-line of the GUD
buffer.

 > BTW,  my earlier emacs version was 21.2.4 and now it is 22.0.50.1
 > 
 > One more question: I'm still not able to open the file another emacs
 > window. I thought this was supposed happen automatically. In other
 > instances of emacs ( like when debugging apps ) the source code file
 > opens automatically in another emacs window ( vertical split style).

I have some more thoughts but you need to answer my questions for good
communication.

Does kgdb work like gdb?
Is "target remote  /dev/cuad0" a valid kgdb command?

 > Even if it doesn't, when I enter "f" it opens up automatically.

For the source to appear gdb/kgdb must output annotations.  In gdb, this
requires "--fullname" or "-annotate=1" for text mode and "-annotate=3"
for graphical mode.  In Emacs 21 "--fullname" was used but was not visible
to the user.

In Emacs 22, running an app like this:

  Run gdb (like this): gdb myprog

won't display the source, but:

  Run gdb (like this): gdb -annotate=3 myprog

will.  Likewise, I suspect

  Run gdb ( like this ) : kgdb -r /dev/cuad0 kernel.debug

won't display the source, but:

  Run gdb ( like this ) : kgdb -a -a -a -r /dev/cuad0 kernel.debug

will.

 > One possibility is, though i changed the emacs current directory
 > to /usr/obj/usr/src/sys/MYKERNEL/ , the -r /dev/cuad0 option would have
 > changed the default directory, as evident in the file line when a gud
 > window is opened:
 > Current directory is /dev/
 > :(

You really want to find another way of specifying the arguments along the lines
that I suggested, so that the directory doesn't change and you get
*gud-kernel.debug* in the mode-line of the GUD buffer.  However, I think
another way to stop the current directory from changing is to set
gud-chdir-before-run to nil.

One last thing, if you do get it to work well, please e-mail me what you
have learnt so that I can add it to my homepage.

Thanks,

Nick                                           http://www.inet.net.nz/~nickrob

Re: kgdb in emacs

[Sanjeev Kumar.S]

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

I will answer your questions from the beginning:


> When can you use gdb -k?
> With the latest GDB from CVS, I get:
> $ gdb -k
> gdb: unrecognized option `-k'
I believe in newer versions of bsd release we've moved from 
"bsd -k" to  kgdb. I don't know why this decision was made. Maybe
its for some simple reason but I haven't poked around it.

> Run gdb ( like this ) : kgdb -a -a -a kernel.debug
> (kgdb) target remote  /dev/cuad0

kgdb requires either a core file or a device file for remote
debugging. If we issue this command on a local machine this
behavior is pretty straightforward, with no quirkiness.

> I guess you mean Emacs now parses your command line now.

> But presumably you still get *gud-cuad0* in the mode-line of the GUD
> buffer.

Yes. I get the above, but is that an issue ? 

> Does kgdb work like gdb?
yes it works like gdb. In its full glory.

> Is "target remote  /dev/cuad0" a valid kgdb command?

Again, I was not able to get to this point without specifying the 
complete set of arguments while starting. ie. to start i need to specify
-r and the debug file. without that i was not able to start it up.

> Run gdb ( like this ) : kgdb -a -a -a -r /dev/cuad0 kernel.debug

Just -a works for me. "-a -a" or "-a -a -a" and I get some garbled output
on the screen. But still I have an issue, I have to press a "n" or "s" to
get emacs to display the source file. Any way around it ?

> One last thing, if you do get it to work well, please e-mail me what you
> have learnt so that I can add it to my homepage.

Yes...I will do this. I will make a complete document and give one copy
to you and one to the Freebsd doc team. But I will try and get as much
questions resolved in the document, so no one has to waste almost
a day figuring it out like me. 

Regards,
Sanjeev.

Nick Roberts <nickrob@snap.net.nz> wrote:  > Thank you very much Nick, Your clue of emacs version prompted me
 > to upgrade my emacs. after which I'm able to do it.

I guess you mean Emacs now parses your command line now.

But presumably you still get *gud-cuad0* in the mode-line of the GUD
buffer.

 > BTW,  my earlier emacs version was 21.2.4 and now it is 22.0.50.1
 > 
 > One more question: I'm still not able to open the file another emacs
 > window. I thought this was supposed happen automatically. In other
 > instances of emacs ( like when debugging apps ) the source code file
 > opens automatically in another emacs window ( vertical split style).

I have some more thoughts but you need to answer my questions for good
communication.

Does kgdb work like gdb?
Is "target remote  /dev/cuad0" a valid kgdb command?

 > Even if it doesn't, when I enter "f" it opens up automatically.

For the source to appear gdb/kgdb must output annotations.  In gdb, this
requires "--fullname" or "-annotate=1" for text mode and "-annotate=3"
for graphical mode.  In Emacs 21 "--fullname" was used but was not visible
to the user.

In Emacs 22, running an app like this:

  Run gdb (like this): gdb myprog

won't display the source, but:

  Run gdb (like this): gdb -annotate=3 myprog

will.  Likewise, I suspect

  Run gdb ( like this ) : kgdb -r /dev/cuad0 kernel.debug

won't display the source, but:

  Run gdb ( like this ) : kgdb -a -a -a -r /dev/cuad0 kernel.debug

will.

 > One possibility is, though i changed the emacs current directory
 > to /usr/obj/usr/src/sys/MYKERNEL/ , the -r /dev/cuad0 option would have
 > changed the default directory, as evident in the file line when a gud
 > window is opened:
 > Current directory is /dev/
 > :(

You really want to find another way of specifying the arguments along the lines
that I suggested, so that the directory doesn't change and you get
*gud-kernel.debug* in the mode-line of the GUD buffer.  However, I think
another way to stop the current directory from changing is to set
gud-chdir-before-run to nil.

One last thing, if you do get it to work well, please e-mail me what you
have learnt so that I can add it to my homepage.

Thanks,

Nick                                           http://www.inet.net.nz/~nickrob


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

[-- Attachment #1.2: Type: text/html, Size: 4871 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: kgdb in emacs

[Nick Roberts]

 > > Is "target remote  /dev/cuad0" a valid kgdb command?
 > 
 > Again, I was not able to get to this point without specifying the 
 > complete set of arguments while starting. ie. to start i need to specify
 > -r and the debug file. without that i was not able to start it up.

I thought maybe the kernel had a remote stub compiled into it and you could
connect through that.  But I know too little about kgdb, so you really need
to ask Hidetoshi Shimokawa.

 > > Run gdb ( like this ) : kgdb -a -a -a -r /dev/cuad0 kernel.debug
 > 
 > Just -a works for me. "-a -a" or "-a -a -a" and I get some garbled output
 > on the screen. But still I have an issue, I have to press a "n" or "s" to
 > get emacs to display the source file. Any way around it ?

Presumably just "-a" gives you text command mode and not the other buffers
that the screenshot I referred to has (M-x gdb-many-windows will show them
if you are in graphical mode).

To see what kgdb is doing run

  kgdb -a -r /dev/cuad0 kernel.debug

and perhaps

  kgdb -a -a -a -r /dev/cuad0 kernel.debug

from the command line.

With GDB, Emacs uses the marker ^Z^Z to parse the file and line number:

(gdb) b main
Breakpoint 1 at 0x804862c: file myprog.c, line 95.
(gdb) r
Starting program: /home/nickrob/myprog 

Breakpoint 1, main (argc=1, argv=0xbfcfbfd4) at myprog.c:95
^Z^Z/home/nickrob/myprog.c:95:1274:beg:0x804862c
(gdb) 

kgdb should output something similar.  However, I guess the kernel in your
case is already running, so maybe it's a bit like attaching to a process
and perhaps the first marker is missing.


 > > One last thing, if you do get it to work well, please e-mail me what you
 > > have learnt so that I can add it to my homepage.
 > 
 > Yes...I will do this. I will make a complete document and give one copy
 > to you and one to the Freebsd doc team. But I will try and get as much
 > questions resolved in the document, so no one has to waste almost
 > a day figuring it out like me. 

Thanks.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: kgdb in emacs

[Sanjeev Kumar.S]

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

To see what kgdb is doing run

  kgdb -a -r /dev/cuad0 kernel.debug

and perhaps

  kgdb -a -a -a -r /dev/cuad0 kernel.debug

from the command line.

With GDB, Emacs uses the marker ^Z^Z to parse the file and line number:

(gdb) b main
Breakpoint 1 at 0x804862c: file myprog.c, line 95.
(gdb) r
Starting program: /home/nickrob/myprog 

Breakpoint 1, main (argc=1, argv=0xbfcfbfd4) at myprog.c:95
^Z^Z/home/nickrob/myprog.c:95:1274:beg:0x804862c
(gdb) 

kgdb should output something similar.  However, I guess the kernel in your
case is already running, so maybe it's a bit like attaching to a process
and perhaps the first marker is missing.

Sanjeev: I'm using emacs graphical. I see
now what you meant by gdb-many-windows
(locals and breakpoints and stackframes).
and I dont think its got anything to do with
source code display, eg in my case even
after the new break enters the old source code is displayed in the multi-window mode.
and when I do a "n" the current source where the break
hit was displayed. and like in other emacs instances
after the "n" when I do a "f" I get the source
opened in a seperate window if it is not already
opened.
But I think like you said the marker ^Z^Z is 
missing, I dont want to step everytime I
jump into gdb to see where I am in the code.
Any way to get this working ? I tried doing a 
^Z^Z on the emacs window and it minimized  on the first ^Z :). Doesnt want
me to use it anymore.
Regards,
Sanjeev.

       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

[-- Attachment #1.2: Type: text/html, Size: 1859 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: kgdb in emacs

[Nick Roberts]

 > Sanjeev: I'm using emacs graphical. I see
 > now what you meant by gdb-many-windows
 > (locals and breakpoints and stackframes).
 > and I dont think its got anything to do with
 > source code display, eg in my case even
 > after the new break enters the old source code is displayed in the multi-window mode.
 > and when I do a "n" the current source where the break
 > hit was displayed. and like in other emacs instances
 > after the "n" when I do a "f" I get the source
 > opened in a seperate window if it is not already
 > opened.

By break do you mean breakpoint?  (there should be a red bullet in the
fringe by breakpoints).  If so, how does the breakpoint get set?  I'm not
sure what you are saying here.  Sometimes if the source is already in another
window and execution goes there GUD will display in that window and not the
dedicated source buffer.

To generate a log of the transactions between kgdb and Emacs can you please
do the following:

1) Set gdb-enable-debug to t using M-x set-variable.
2) Do M-x gdb and start kgdb with the arguments you are using (and tell me
   what they are).
3) Type 'n' or 's' to get the source buffer to display.
4) Post the value of gdb-debug-log to me (it may be large and is not of
   interest to the list).

 > But I think like you said the marker ^Z^Z is 
 > missing, I dont want to step everytime I
 > jump into gdb to see where I am in the code.
 > Any way to get this working ? I tried doing a 
 > ^Z^Z on the emacs window and it minimized  on the first ^Z :). Doesnt want
 > me to use it anymore.

The ^Z^Z markers that GDB outputs are characters that are processed by the
process-filter and are not related to ^Z typed from the keyboard which is
bound to the command suspend-frame.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Mysterious hidden end of line characters.

[Peter Dyballa]

Am 26.01.2008 um 18:14 schrieb David:

> How might I try to identify what is going on here?


You could have used a *-dos or *-mac encoding, which have two  
characters as line endings: line feed-carriage return or carriage  
return-line feed. This might cause trouble. You can check this by  
clicking with the mouse cursor onto the encoding marker in mode-line  
– at least in GNU Emacs 22. Otherwise there is describe-encoding.

But the *BIG* question is: why and for what do you need some external  
terminal application?!

In GNU Emacs you can imitate your behaviour by creating a *shell*  
buffer (M-x shell RET). In this *shell* buffer you have all that  
available what GNU Emacs can do, for example "flattening" your  
configure invocation.

It's possible too to use the *scratch* buffer to prepare such a long  
and complicated line.

And finally, the top choice: use compile! M-x compile RET and remove  
whatever you see in minibuffer, then paste (yank) the configure  
invocation as one line. You're still able to edit this line, isearch,  
whatever – and remove that "2>&1 | tee config_log.txt" ballast! Press  
RET. Isn't what you now see much nicer with the colourful faces? You  
can save that buffer – and you better kill it, that compile does not  
overwrite it when you start to really compile the software!

GNU Emacs can even remember your compile commands (M-x compile RET UP  
UP). IMO it's better not to rely on bash and explicitly use

	env <whichever environment settings> <the command>


And there is one situation when it's rather useful to configure in  
*compilation* buffer: when the line of input is too long for the  
shell to handle interactively.

--
Greetings

   Pete

The light at the end of the tunnel has been turned off due to budget  
cuts.

Re: Mysterious hidden end of line characters.

[David]

Thanks Pete for you reply.

> You could have used a *-dos or *-mac encoding, which have two  
> characters as line endings: line feed-carriage return or carriage  
> return-line feed. This might cause trouble. You can check this by  
> clicking with the mouse cursor onto the encoding marker in mode-line  
> ? at least in GNU Emacs 22. Otherwise there is describe-encoding.

In emacs 21 the equivelent is M-x describe-coding-system. Right now
this is defined as undecided-unix which is repressented as -- in the
mode-line. Perhaps for some reason this was not the case last week
when my colleague complained about -dos coding.
 
> But the *BIG* question is: why and for what do you need some
> external terminal application?!  In GNU Emacs you can imitate your
> behaviour by creating a *shell* buffer (M-x shell RET). In this
> *shell* buffer you have all that available what GNU Emacs can do,
> for example "flattening" your configure invocation.


Ha ha, I thought someone might spot this. After 2 years of emacs use I
still have one or two newbie feathers lerking in my plummage. I do use
*shell* buffers alot, but there is some terminal functionality which I
do not have.

Examples of commands in a *shell* buffer which for me don't work as in
a terminal include

1) shell_prompt:~$ man pwd ## (or any other command), this gives
something rather unfriendly in emacs. Only today did I discover M-x
man was the proper way to do this. Nice feature, but rather
non-evident to the newbie. Why is *shell* not totally equivelent to a
terminal?

2) shell_prompt:~$ grass ## Similarly to typing man at the prompt, the
lack of terminal functionality used to prevent me from passing the
terminal based setup page. I recently discoverred the solution (for
older versions of GRASS) was to add a flag specifying a GUI setup
page. Also updating to more recent versions appears to avoid this
problem. So now I am finally using GRASS in emacs (horrah!).

3) shell_prompt:~$ mutt ## Similarly, I cannot find a way to navigate
my mail boxes using mutt inside emacs. Emacs just isn't displaying
anything that would normally appear in the terminal apart from when I
hit q it asks if I really want to quit - of course I do, I can't see
anything! The best I can do is to run mutt in the terminal, pass to
emacs to write messages and pass back to the terminal to handle
attachments etc. What am I missing?

4) shell_prompt:~$ su ## I never like moving to super user in emacs
because the password appears on screen as I type it. So all
administration is terminal based for me. How to hide passwords as a
terminal would?



> It's possible too to use the *scratch* buffer to prepare such a long  
> and complicated line.
> 
> And finally, the top choice: use compile! M-x compile RET and remove  
> whatever you see in minibuffer, then paste (yank) the configure  
> invocation as one line. You're still able to edit this line, isearch,  
> whatever ? and remove that "2>&1 | tee config_log.txt" ballast! Press  
> RET. Isn't what you now see much nicer with the colourful faces? You  
> can save that buffer ? and you better kill it, that compile does not  
> overwrite it when you start to really compile the software!
> 
> GNU Emacs can even remember your compile commands (M-x compile RET UP  
> UP). IMO it's better not to rely on bash and explicitly use
> 
> 	env <whichever environment settings> <the command>
> 
> 
> And there is one situation when it's rather useful to configure in  
> *compilation* buffer: when the line of input is too long for the  
> shell to handle interactively.

Wow, that sounds awesome. I'll bear it in mind for next time.
cheers
David

Re: Mysterious hidden end of line characters.

[Tim X]

David <dpleydel@univ-fcomte.fr> writes:

>
> Ha ha, I thought someone might spot this. After 2 years of emacs use I
> still have one or two newbie feathers lerking in my plummage. I do use
> *shell* buffers alot, but there is some terminal functionality which I
> do not have.
>
> Examples of commands in a *shell* buffer which for me don't work as in
> a terminal include
>
> 1) shell_prompt:~$ man pwd ## (or any other command), this gives
> something rather unfriendly in emacs. Only today did I discover M-x
> man was the proper way to do this. Nice feature, but rather
> non-evident to the newbie. Why is *shell* not totally equivelent to a
> terminal?

The command M-x shell gives you a 'dumb' terminal. This means any
program that relies on terminal IO to display correctly wil fail. for
programs like this, use M-x term. 

>
> 2) shell_prompt:~$ grass ## Similarly to typing man at the prompt, the
> lack of terminal functionality used to prevent me from passing the
> terminal based setup page. I recently discoverred the solution (for
> older versions of GRASS) was to add a flag specifying a GUI setup
> page. Also updating to more recent versions appears to avoid this
> problem. So now I am finally using GRASS in emacs (horrah!).
>

Again, M-x term may be a better solution. Of course, you could just
write a special grass-mode and stick it up on emacswiki :)

> 3) shell_prompt:~$ mutt ## Similarly, I cannot find a way to navigate
> my mail boxes using mutt inside emacs. Emacs just isn't displaying
> anything that would normally appear in the terminal apart from when I
> hit q it asks if I really want to quit - of course I do, I can't see
> anything! The best I can do is to run mutt in the terminal, pass to
> emacs to write messages and pass back to the terminal to handle
> attachments etc. What am I missing?
>

I think there may be amode out there for running mutt in emacs. However,
maybe switch to a native emacs mail client. If you use IMAP, you could
use one of the many emacs mail clients that support imap and then when
your not in emcs, you can use mutt and still have access to all your
mail. There are also interfaces to gmail. 

> 4) shell_prompt:~$ su ## I never like moving to super user in emacs
> because the password appears on screen as I type it. So all
> administration is terminal based for me. How to hide passwords as a
> terminal would?
>
I don't get this problem using M-x term
I also use tramp to edit files owned by others from within emacs
i.e. /root@localhost:/path/to/file

Use M-x shell only when you want to execute simple line oriented
programs that don't need things like ncurses or formatted screen IO. 

finally, if your someone who likes to use lisp at the shell level and
have nice integration with emacs, have a look at the emacs shell - type
M-x eshell

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

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

> David <dpleydel@univ-fcomte.fr> writes:
>
>>
>> Ha ha, I thought someone might spot this. After 2 years of emacs use I
>> still have one or two newbie feathers lerking in my plummage. I do use
>> *shell* buffers alot, but there is some terminal functionality which I
>> do not have.
>>
>> Examples of commands in a *shell* buffer which for me don't work as in
>> a terminal include
>>
>> 1) shell_prompt:~$ man pwd ## (or any other command), this gives
>> something rather unfriendly in emacs. Only today did I discover M-x
>> man was the proper way to do this. Nice feature, but rather
>> non-evident to the newbie. Why is *shell* not totally equivelent to a
>> terminal?
>
> The command M-x shell gives you a 'dumb' terminal. This means any
> program that relies on terminal IO to display correctly wil fail. for
> programs like this, use M-x term. 
>
>>
>> 2) shell_prompt:~$ grass ## Similarly to typing man at the prompt, the
>> lack of terminal functionality used to prevent me from passing the
>> terminal based setup page. I recently discoverred the solution (for
>> older versions of GRASS) was to add a flag specifying a GUI setup
>> page. Also updating to more recent versions appears to avoid this
>> problem. So now I am finally using GRASS in emacs (horrah!).
>>
>
> Again, M-x term may be a better solution. Of course, you could just
> write a special grass-mode and stick it up on emacswiki :)
>
>> 3) shell_prompt:~$ mutt ## Similarly, I cannot find a way to navigate
>> my mail boxes using mutt inside emacs. Emacs just isn't displaying
>> anything that would normally appear in the terminal apart from when I
>> hit q it asks if I really want to quit - of course I do, I can't see
>> anything! The best I can do is to run mutt in the terminal, pass to
>> emacs to write messages and pass back to the terminal to handle
>> attachments etc. What am I missing?
>>
>
> I think there may be amode out there for running mutt in emacs. However,
> maybe switch to a native emacs mail client. If you use IMAP, you could
> use one of the many emacs mail clients that support imap and then when
> your not in emcs, you can use mutt and still have access to all your
> mail. There are also interfaces to gmail. 
>
>> 4) shell_prompt:~$ su ## I never like moving to super user in emacs
>> because the password appears on screen as I type it. So all
>> administration is terminal based for me. How to hide passwords as a
>> terminal would?
>>
If you start emacs with LC_ALL=C the prompt for password will be
Password:
and will be hidden.
The problem is when locale is french or else maybe, the regex that
match "Mot de passe :" don't exist.

I tried to modify it but without success .
It is in comint.el:

(defcustom comint-password-prompt-regexp
  "\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|\
Kerberos \\|CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)\
\[Pp]assword\\( (again)\\)?\\|\
pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\
\\(?:, try again\\)?\\(?: for [^:]+\\)?:\\s *\\'"
  "*Regexp matching prompts for passwords in the inferior process.
This is used by `comint-watch-for-password-prompt'."
  :type 'regexp
  :group 'comint)


If some body find how to modify that it's welcome

> I don't get this problem using M-x term
> I also use tramp to edit files owned by others from within emacs
> i.e. /root@localhost:/path/to/file
>
> Use M-x shell only when you want to execute simple line oriented
> programs that don't need things like ncurses or formatted screen IO. 
>
> finally, if your someone who likes to use lisp at the shell level and
> have nice integration with emacs, have a look at the emacs shell - type
> M-x eshell
>
> Tim

-- 
A + Thierry
Pub key: http://pgp.mit.edu

Re: Mysterious hidden end of line characters.

[Peter Dyballa]

Am 31.01.2008 um 11:20 schrieb Thierry Volpiatto:

> The problem is when locale is french or else maybe, the regex that
> match "Mot de passe :" don't exist.

Could be this works:

	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos \\| 
CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\ 
\)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\ 
(?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'"


It's a very complicated structure that takes into account that you  
might fail to enter correctly a Kerberos, or CVS, or SMB, or LDAP  
password, some pass phrase, and I don't know what else.

Forgetting all this troublesome stuff, just describe another option

	\\|Mot de passe

with a final SPC that is then followed by

	?\\(?: for [^:]+\\)

so you have to put everything before this expression into a froup  
with \\(...\\). Or this is more correct?

	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos \\| 
CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\ 
\)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\ 
(?:, try again\\)?\\(?: for [^:]+\\)\\|Mot de passe \\)?:\\s *\\'"

Mostly guessing, not completely understanding.

--
Greetings

   Pete

Isn't vi that text editor with two modes... one that beeps and one  
that corrupts your file?
				– Dan Jacobson, on comp.os.linux.advocacy

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 31.01.2008 um 11:20 schrieb Thierry Volpiatto:
>
>> The problem is when locale is french or else maybe, the regex that
>> match "Mot de passe :" don't exist.
>
> Could be this works:
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'"
>
>
> It's a very complicated structure that takes into account that you
> might fail to enter correctly a Kerberos, or CVS, or SMB, or LDAP
> password, some pass phrase, and I don't know what else.
>
> Forgetting all this troublesome stuff, just describe another option
>
> 	\\|Mot de passe
>
> with a final SPC that is then followed by
>
> 	?\\(?: for [^:]+\\)
>
> so you have to put everything before this expression into a froup with
> \\(...\\). Or this is more correct?
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)?\\(?: for [^:]+\\)\\|Mot de passe \\)?:\\s *\\'"
>
> Mostly guessing, not completely understanding.

I will try again to modify this with your advices,
another thing is (that don't appear in this mail)
after Mot de passe there is a "_" and then ":"
The "_" is in blue and i think it's not a litteral "_"
but an unicode char or something like that but i don't
know what it is exactly.
May be it's why all the regex i tried before failed ?

-- 
A + Thierry
Pub key: http://pgp.mit.edu

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 31.01.2008 um 11:20 schrieb Thierry Volpiatto:
>
>> The problem is when locale is french or else maybe, the regex that
>> match "Mot de passe :" don't exist.
>
> Could be this works:
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'"
>
>
> It's a very complicated structure that takes into account that you
> might fail to enter correctly a Kerberos, or CVS, or SMB, or LDAP
> password, some pass phrase, and I don't know what else.
>
> Forgetting all this troublesome stuff, just describe another option
>
> 	\\|Mot de passe
>
> with a final SPC that is then followed by
>
> 	?\\(?: for [^:]+\\)
>
> so you have to put everything before this expression into a froup with
> \\(...\\). Or this is more correct?
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)?\\(?: for [^:]+\\)\\|Mot de passe \\)?:\\s *\\'"
>
> Mostly guessing, not completely understanding.
Not working for the moment, i keep trying.
What i find is that Mot de passe_: is 
Mot de passe.:

Here is the describe of the character:


        character:   (160, #o240, #xa0)
preferred charset: iso-8859-1 (Latin-1 (ISO/IEC 8859-1))
       code point: 0xA0
           syntax: . 	which means: punctuation
         category: b:Arabic j:Japanese l:Latin
      buffer code: #xC2 #xA0
        file code: #xC2 #xA0 (encoded by coding system utf-8)
          display: by this font (glyph code)
     courier:pixelsize=14:foundry=adobe:weight=bold:slant=r:width=normal (#x61)
   hardcoded face: nobreak-space

Character code properties are not shown: customize what to show

There is an overlay here:
 From 1 to 17
  face                 regex-tool-matched-face

\([Mot de passe]*.*:*[blank]?\)
that regex work in regex-tool but don't work in the whole regexp

-- 
A + Thierry
Pub key: http://pgp.mit.edu

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 31.01.2008 um 11:20 schrieb Thierry Volpiatto:
>
>> The problem is when locale is french or else maybe, the regex that
>> match "Mot de passe :" don't exist.
>
> Could be this works:
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'"
>
>
> It's a very complicated structure that takes into account that you
> might fail to enter correctly a Kerberos, or CVS, or SMB, or LDAP
> password, some pass phrase, and I don't know what else.
>
> Forgetting all this troublesome stuff, just describe another option
>
> 	\\|Mot de passe
>
> with a final SPC that is then followed by
>
> 	?\\(?: for [^:]+\\)
>
> so you have to put everything before this expression into a froup with
> \\(...\\). Or this is more correct?
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)?\\(?: for [^:]+\\)\\|Mot de passe \\)?:\\s *\\'"
>
> Mostly guessing, not completely understanding.

Sorry, your first one seem good:

(setq comint-password-prompt-regexp 
      "\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
\\|
CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
\)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
(?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'")

I keep trying but it seem working.

-- 
A + Thierry
Pub key: http://pgp.mit.edu

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 31.01.2008 um 11:20 schrieb Thierry Volpiatto:
>
>> The problem is when locale is french or else maybe, the regex that
>> match "Mot de passe :" don't exist.
>
> Could be this works:
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'"
>
>
> It's a very complicated structure that takes into account that you
> might fail to enter correctly a Kerberos, or CVS, or SMB, or LDAP
> password, some pass phrase, and I don't know what else.
>
> Forgetting all this troublesome stuff, just describe another option
>
> 	\\|Mot de passe
>
> with a final SPC that is then followed by
>
> 	?\\(?: for [^:]+\\)
>
> so you have to put everything before this expression into a froup with
> \\(...\\). Or this is more correct?
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)?\\(?: for [^:]+\\)\\|Mot de passe \\)?:\\s *\\'"
>
> Mostly guessing, not completely understanding.

I have tested it in ubuntu and here in gentoo
Tramp prompt, sudo are not affected, it work.

So here to have password hidden with french prompt:

(setq comint-password-prompt-regexp 
      "\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
\\|
CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
\)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
(?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'")

Thank you for your help.

-- 
A + Thierry
Pub key: http://pgp.mit.edu

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 31.01.2008 um 11:20 schrieb Thierry Volpiatto:
>
>> The problem is when locale is french or else maybe, the regex that
>> match "Mot de passe :" don't exist.
>
> Could be this works:
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'"
>
>
> It's a very complicated structure that takes into account that you
> might fail to enter correctly a Kerberos, or CVS, or SMB, or LDAP
> password, some pass phrase, and I don't know what else.
>
> Forgetting all this troublesome stuff, just describe another option
>
> 	\\|Mot de passe
>
> with a final SPC that is then followed by
>
> 	?\\(?: for [^:]+\\)
>
> so you have to put everything before this expression into a froup with
> \\(...\\). Or this is more correct?
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)?\\(?: for [^:]+\\)\\|Mot de passe \\)?:\\s *\\'"
>
> Mostly guessing, not completely understanding.

As you warn me at the start of this post,
i have strange effect with this regex:
when i do tar command i have a prompt like "tar: "
when i launch a script python with some raw-input,
in a python-shell (ipython) the prompt is hidden like a password.

So i tried to modify the regex again:
I can have a prompt for su correct but always with side effects on 
some other commands.

I think the best should be modifying bash to avoid this stupid
"Mot de passe : " and have a normal "Password: "
without modifying the locale env variables.
But i don't know where i can modify that for the moment.

If emacs is started with LC_ALL=C the prompt is "Password: "
Thats a way to do but some errors can appear on french files(not sure)

-- 
A + Thierry
Pub key: http://pgp.mit.edu

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 31.01.2008 um 11:20 schrieb Thierry Volpiatto:
>
>> The problem is when locale is french or else maybe, the regex that
>> match "Mot de passe :" don't exist.
>
> Could be this works:
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'"
>
>
> It's a very complicated structure that takes into account that you
> might fail to enter correctly a Kerberos, or CVS, or SMB, or LDAP
> password, some pass phrase, and I don't know what else.
>
> Forgetting all this troublesome stuff, just describe another option
>
> 	\\|Mot de passe
>
> with a final SPC that is then followed by
>
> 	?\\(?: for [^:]+\\)
>
> so you have to put everything before this expression into a froup with
> \\(...\\). Or this is more correct?
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)?\\(?: for [^:]+\\)\\|Mot de passe \\)?:\\s *\\'"
>
> Mostly guessing, not completely understanding.

Finally, i found the best solution, without modifying the regex:
Just set in .bashrc an alias ==> alias su="LC_ALL su -l"
Like that the prompt is password, is hidden and when you are root,
if you do echo $LC_ALL, the env variable is unchanged (-l option of su)
fr_FR.UTF-8 for me.
Thats much more safe than modifying the comint regex.

-- 
A + Thierry
Pub key: http://pgp.mit.edu

Re: Mysterious hidden end of line characters.

[Thierry Volpiatto]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 31.01.2008 um 11:20 schrieb Thierry Volpiatto:
>
>> The problem is when locale is french or else maybe, the regex that
>> match "Mot de passe :" don't exist.
>
> Could be this works:
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)\\|Mot de passe \\)?\\(?: for [^:]+\\)?:\\s *\\'"
>
>
> It's a very complicated structure that takes into account that you
> might fail to enter correctly a Kerberos, or CVS, or SMB, or LDAP
> password, some pass phrase, and I don't know what else.
>
> Forgetting all this troublesome stuff, just describe another option
>
> 	\\|Mot de passe
>
> with a final SPC that is then followed by
>
> 	?\\(?: for [^:]+\\)
>
> so you have to put everything before this expression into a froup with
> \\(...\\). Or this is more correct?
>
> 	"\\(\\(\\(Enter \\|[Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos
> \\|
> CVS \\|UNIX \\| SMB \\|LDAP \\|\\[sudo] \\|^\\)[Pp]assword\\( (again)\
> \)?\\|pass phrase\\|\\(Enter \\|Repeat \\|Bad \\)?[Pp]assphrase\\)\\
> (?:, try again\\)?\\(?: for [^:]+\\)\\|Mot de passe \\)?:\\s *\\'"
>
> Mostly guessing, not completely understanding.

For eshell, add alias for su like that:
alias 'LC_ALL=C su -l'

thought the regex i gave in last posts seem safe, but that is much
better.

-- 
A + Thierry
Pub key: http://pgp.mit.edu