Re: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
Jarl> Jarl Friis <jarl(a)diku.dk> writes:
> Jarl Friis <jarl(a)diku.dk> writes:
>
> >
> > I must admit that the problem seems deeper than just cvs gives
> > non-parseable feedback something lurking in either the *usage* of
> > xemacs network features within pcl-cvs or the implementation of the
> > XEmacs network features.
>
> Sorry, it seem not to be related to networking, since pcl-cvs is not
> directly using the XEmacs network features, but just invokes cvs as a
> process, nevertheless I consider it a XEmacs bug, but merely related
> to the `start-process' function.
Jarl> I have made a very small program that demonstrates the
Jarl> location of the bug. Essentially it is setting the variable
Jarl> `process-connection-type' to nil that causes trouble. In the
Hi Jarl,
thanks for narrowing in on this!
I am using a slightly modified version which names the process buffers
uniquely so I can diff them afterwards.
Could you please do the same on send in the diffs?
I am not getting any diffs in cvs output in native Windows 2000 XEmacs
on all of of XEmacs packages module monster!
On a second try I got following diff which I think is unrelated
(waiting for a lock in CVS):
--- C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYA2he Thu Jan 24 23:23:03 2002
+++ C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYADsk Thu Jan 24 23:23:03 2002
＠＠ -15338,6 +15338,8 ＠＠
Sticky Options: (none)
cvs server: Examining xemacs-packages/ilisp
+cvs server: [23:05:53] waiting for cvs's lock in
/pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp
+cvs server: [23:06:23] obtained lock in
/pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp
===================================================================
File: .cvsignore Status: Up-to-date
＠＠ -31917,4 +31919,4 ＠＠
Sticky Options: (none)
-Process mycvs finished
+Process mycvs<1> finished
Jarl> examples, please modify the hardcoded strings as necessary.
Jarl> The first one makes a cvs status using pipes, which creates spurious
Jarl> output in " *mycvs-tmp*" buffer:
Jarl> (let (
Jarl> (process-connection-type nil) ; Use a pipe, not a pty.
Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq"))
Jarl> )
Jarl> (apply 'start-process "mycvs" (get-buffer-create "
*mycvs-tmp*") "cvs" '("-f" "status"))
Jarl> )
Jarl> The second one uses a pty instead, and sends the password
"manually",
Jarl> which works!
Jarl> (let (
Jarl> (mypassword "PaSsWoRd");;insert a password here
Jarl> (process-connection-type t) ; Use a pipe, not a pty.
Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq"))
Jarl> )
Jarl> (apply 'start-process "mycvs" (get-buffer-create "
*mycvs-tmp*") "cvs" '("-f" "status"))
Jarl> (process-send-string "mycvs" (concat mypassword "\n"))
Jarl> )
Jarl> Now the usage of `process-connection-type' is not to be found in
Jarl> `start-process' so I guess it is used in `start-process-internal'
Jarl> which is implemented in C, will someone please take over from here?
Ah,
xemacs-21.5\src\process-unix.c
allocates a pty for process-connection-type t, while
xemacs-21.5\src\process-nt.c
is not doing anything with process-connection-type!
This is probably why I don't see this kind of problem.
In xemacs-21.5\src\process-unix.c there is ...
static int
unix_create_process (Lisp_Process *p,
Lisp_Object *argv, int nargv,
Lisp_Object program, Lisp_Object cur_dir)
{
int pid;
int inchannel = -1;
int outchannel = -1;
/* Use volatile to protect variables from being clobbered by longjmp. */
volatile int forkin = -1;
volatile int forkout = -1;
volatile int pty_flag = 0;
if (!NILP (Vprocess_connection_type))
{
/* find a new pty, open the master side, return the opened
file handle, and store the name of the corresponding slave
side in global variable pty_name. */
outchannel = inchannel = allocate_pty ();
}
Jarl> Now when the bug tracks into the C-code I guess it is relevant with
Jarl> system information, how can I have XEmacs collect all the information
Jarl> necessary for this? In short I run XEmacs 21.1.14, 21.5.4, linux,
If necessary/possible, please install the latest net-utils package (>=
1.23) and then use
Help->Send Bug Report...
or
M-x report-emacs-bug
as suggested in
http://www.xemacs.org/Debug/index.html
Jarl> $ gcc -v
Jarl> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
Jarl> gcc version 2.95.3 20010315 (SuSE)
Jarl> Will someone please take over from here as I am not familiar with
Jarl> XEmacs C code?
Thanks for tracking this down, Jarl. This should bring us a lot
closer to a solution!
I'll be skiing for a week starting saturday.
I hope somebody will take this up meanwhile.
Best regards,
Adrian
Jarl> Jarl
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/