cd - in shell buffers does not work any more

cd - in shell buffers does not work any more

[Francesco Potorti`]

GNU Emacs 21.2.50.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2002-03-20 on pot.cnuce.cnr.it from the CVS

If I type `cd -' in a shell buffer I get an error:

cd: No such directory found via CDPATH environment variable

I am sure I did not get this error before (that is, with the latest
pretest).  And I seem to believe that it worked too, that is, shell mode
was able to track the directory change.

By the way, is it correct ot report here bugs found in the CVS version,
without a patch, or should I write to emacs-pretest-bug@gnu.org
instead, as the report-emacs-bug command would do?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: cd - in shell buffers does not work any more

[Eli Zaretskii]

> From: Francesco Potorti` <pot@gnu.org>
> Date: Fri, 22 Mar 2002 15:03:10 +0100
> 
> By the way, is it correct ot report here bugs found in the CVS version,
> without a patch, or should I write to emacs-pretest-bug@gnu.org
> instead, as the report-emacs-bug command would do?

Please use emacs-pretest-bug.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: cd - in shell buffers does not work any more

[Richard Stallman]

    By the way, is it correct ot report here bugs found in the CVS version,
    without a patch, or should I write to emacs-pretest-bug@gnu.org
    instead, as the report-emacs-bug command would do?

I don't think it makes much difference.

    If I type `cd -' in a shell buffer I get an error:

    cd: No such directory found via CDPATH environment variable

Tht is very strange, since it seems to be an error from the shell.  (I
don't know what `cd -' is supposed to do.)


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: cd - in shell buffers does not work any more

[Francesco Potorti`]

       If I type `cd -' in a shell buffer I get an error:
   
       cd: No such directory found via CDPATH environment variable
   
   Tht is very strange, since it seems to be an error from the shell.  (I
   don't know what `cd -' is supposed to do.)
   
cd - swaps the two top entries in the cd history stack of the shell.
Basically, it brings you to the dir where you have last been.

Anyway, it is true that it is a strange error.  For that emacs, I can
reliably make it crash really simply with shell.el:

emacs -q
M-x shell RET
C-d              --> signal 11

GNU Emacs 21.2.50.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2002-03-20 on pot.cnuce.cnr.it

I am updating from the latest sources before investigating that.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: cd - in shell buffers does not work any more

[Pavel Janík]

[ This is for Kim, IMO. ]

   From: Francesco Potorti` <pot@gnu.org>
   Date: Mon, 25 Mar 2002 10:50:39 +0100

   > emacs -q
   > M-x shell RET
   > C-d              --> signal 11

emacs -q -f shell -eval '(comint-delchar-or-maybe-eof 1)'

(gdb) run -q -f shell -eval '(comint-delchar-or-maybe-eof 1)'
Starting program: /usr/src/packages/BUILD/emacs-21.2.50/src/emacs -q -f shell -eval '(comint-delchar-or-maybe-eof 1)'

Program received signal SIGSEGV, Segmentation fault.
0x08158de3 in Fprocess_send_eof (process=405319612) at process.c:5438
5438      if (DATAGRAM_CONN_P (process))
(gdb) backtrace
#0  0x08158de3 in Fprocess_send_eof (process=405319612) at process.c:5438
#1  0x0812a29b in Ffuncall (nargs=1, args=0xbfffe924) at eval.c:2712
#2  0x0815106c in Fbyte_code (bytestr=944222300, vector=1212427224, maxdepth=2)
    at bytecode.c:709
#3  0x0812a7e7 in funcall_lambda (fun=1212414344, nargs=0, 
    arg_vector=0xbfffea28) at eval.c:2899
#4  0x0812a399 in Ffuncall (nargs=1, args=0xbfffea24) at eval.c:2769
#5  0x0815106c in Fbyte_code (bytestr=944222332, vector=1212539528, maxdepth=4)
    at bytecode.c:709
#6  0x0812a7e7 in funcall_lambda (fun=1212448224, nargs=1, 
    arg_vector=0xbfffead4) at eval.c:2899
#7  0x0812a4e5 in apply_lambda (fun=1212448224, args=1480755676, eval_flag=1)
    at eval.c:2821
#8  0x08129a7f in Feval (form=1480755684) at eval.c:2129
#9  0x0812a29b in Ffuncall (nargs=2, args=0xbfffec34) at eval.c:2712
#10 0x0815106c in Fbyte_code (bytestr=941816580, vector=1210253164, 
    maxdepth=11) at bytecode.c:709
#11 0x0812a7e7 in funcall_lambda (fun=1210252004, nargs=1, 
    arg_vector=0xbfffed58) at eval.c:2899
#12 0x0812a399 in Ffuncall (nargs=2, args=0xbfffed54) at eval.c:2769
#13 0x0815106c in Fbyte_code (bytestr=941802888, vector=1210239564, maxdepth=6)
    at bytecode.c:709
#14 0x0812a7e7 in funcall_lambda (fun=1210238320, nargs=0, 
---Type <return> to continue, or q <return> to quit---
    arg_vector=0xbfffee68) at eval.c:2899
#15 0x0812a399 in Ffuncall (nargs=1, args=0xbfffee64) at eval.c:2769
#16 0x0815106c in Fbyte_code (bytestr=941798356, vector=1210233956, maxdepth=5)
    at bytecode.c:709
#17 0x0812a7e7 in funcall_lambda (fun=1210233788, nargs=0, 
    arg_vector=0xbfffef24) at eval.c:2899
#18 0x0812a4e5 in apply_lambda (fun=1210233788, args=405319612, eval_flag=1)
    at eval.c:2821
#19 0x08129a7f in Feval (form=1480508668) at eval.c:2129
#20 0x080d4a6c in top_level_2 () at keyboard.c:1261
#21 0x08128825 in internal_condition_case (bfun=0x80d4a58 <top_level_2>, 
    handlers=405416076, hfun=0x80d47a8 <cmd_error>) at eval.c:1334
#22 0x080d4a9b in top_level_1 () at keyboard.c:1269
#23 0x081283b1 in internal_catch (tag=405377404, func=0x80d4a70 <top_level_1>, 
    arg=405319612) at eval.c:1094
#24 0x080d49d9 in command_loop () at keyboard.c:1230
#25 0x080d4554 in recursive_edit_1 () at keyboard.c:957
#26 0x080d4680 in Frecursive_edit () at keyboard.c:1013
#27 0x080d34c5 in main (argc=6, argv=0xbffff564, envp=0xbffff580)
    at emacs.c:1604
#28 0x4030c9ed in __libc_start_main () from /lib/libc.so.6

Current CVS.
-- 
Pavel Janík

Make sure all variables are initialised before use.
                  --  The Elements of Programming Style (Kernighan & Plaugher)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: cd - in shell buffers does not work any more

[Francesco Potorti`]

   Current CVS.

Yes, I can reproduce it reliably.  The problem is that DATAGRAM_CONN_P
indexes an array using (correctly) (Lisp_Process *)->infd, but infd
appears to be corrupt:

Program received signal SIGSEGV, Segmentation fault.
0x08158d43 in Fprocess_send_eof (process=405319196) at process.c:5438
(gdb) xprocess 405319196
$5 = (struct Lisp_Process *) 0x828ae1c
{
  size = 10, 
  v_next = 0x818a5b8, 
  infd = 405319196, 
  outfd = 405319220, 
  subtty = 405319196, 
  tty_name = 0, 
  name = 0, 
  command = 135833036, 
  filter = 405319220, 
  sentinel = 405319220, 
  log = 405319196, 
  buffer = 0, 
  pid = 10, 
  command_channel_p = 135833060, 
  childp = 405319244, 
  mark = 405319220, 
  kill_without_query = 1479449932, 
  raw_status_low = 0, 
  raw_status_high = 8, 
  status = 135833080, 
  pty_flag = 405319220, 
  tick = 405319220, 
  update_tick = 405319196, 
  decode_coding_system = 0, 
  decoding_buf = 8, 
  decoding_carryover = 135833120, 
  encode_coding_system = 405319220, 
  encoding_buf = 405319220, 
  encoding_carryover = 1479059972, 
  inherit_coding_system_flag = 0
}

Notice that 405319196 is a value common to infd, subtty, log and
update_tick, and is 0x1828ae1c, that is, the address of the process
structure & 0x10000000.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: cd - in shell buffers does not work any more

[Richard Stallman]

`cd -' works ok for me.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: cd - in shell buffers does not work any more

[Pavel Janík]

   From: Francesco Potorti` <pot@gnu.org>
   Date: Mon, 25 Mar 2002 13:38:26 +0100

   >    Current CVS.
   > 
   > Yes, I can reproduce it reliably.  The problem is that DATAGRAM_CONN_P
   > indexes an array using (correctly) (Lisp_Process *)->infd, but infd
   > appears to be corrupt:
   > 
   > Program received signal SIGSEGV, Segmentation fault.

Miles fixed this in CVS.
-- 
Pavel Janík

panic("bad_user_access_length executed (not cool, dude)");
                  -- 2.0.38 kernel/panic.c

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel