February 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: rssh.el interactions with ange-ftp/efs 25 years, 2 months

Jan Vroonhof

Sandy Rutherford <sandy(a)math.ubc.ca> writes: > As I've mentioned before, there is another and much tougher issue than > simply using URLs to specify file names. EFS cannot use a file > transfer program that does not follow a protocol. We are not proposing EFS be extended to handle other transfer programs. I am proposing allowing other handlers for remote protocols. The would need two things 1. A way to access a file using a particular handler. I proposed a syntax for that. The consensus seems to be that it is worth trying to use URL's. 2. A general method of specifying remote files is specified and logic is added to Emacs to support automatic selection of handler. I propose we use the EFS syntax for that as it is clean and short. Under this proposal EFS would become the handler for ftp:// URLS and the default action for a general remote name would we be to convert it to ftp:// for backwards compatibility. > Neither of rcp, scp, or ssh (or even sftp) provide status information > back, nor do they follow any defined protocol. They are designed as > user-level programs. EFS will not work with them now, nor will it > ever work with them. EFS might not work with them but rssh.el does. > Therefore, the main reason for supporting URLs is not to allow people > to use rcp, scp, etc, but to provide the convenience of having EFS > support a widespread syntax. Support for URLs will not lead to > support for rcp, scp, etc. We already _have_ support for rsh style transfers with rssh.el. The problem is just that A. now it uses a remote file syntax that conflicts partly with EFS. B. The user has to select by hand which protocol to use. i.e. EFS thinks its the sole provider of remote file access. > To summarise, there are 3 issues swirling around here: Like I said, I think you are completely misrepresenting things here. > 1. URL support. This is a user interface issue. Some work will need > to be done to make it compatible with Emacs, but this is a > possibility (maybe even a likelhood). No it is a technical issue. We need a syntax for remote files that can hold a protocol. That the choice is URL's is maybe user interface stuff. > 2. Support for rcp, scp and sftp. This is a non-starter. See rssh.el > 3. Support for secure file transfers. Via ftpsshd and SSLftp we have > support for this now. However, we can probably do some things to > make it easier to set up EFS to use them. This is completely separate from this discssing.

2 participants
1 comments

Bug or feature? - file-regular-p 25 years, 2 months

Carsten Leonhardt

Hi! Today I was wondering why a function wouldn't work when given a remote directory. The function essentially looks for (regular) files in the directory, which it then moves to another location. Well, look for yourselves at the tests I made (also verified on XEmacs 20.4, and on Emacs 19.34). Considering the fact that file-directory-p and file-symlink-p work correctly with remote locations, I'd say that file-regular-p is broken. Further down is what I believe to be another example of it's brokenness ("/vmlinuz" *is* a symlink). (file-regular-p "/etc/passwd") => t (file-regular-p "/leo＠localhost:/etc/passwd") => nil (file-directory-p "/etc") => t (file-directory-p "/leo＠localhost:/etc") => t (file-symlink-p "/vmlinuz") => "boot/vmlinuz-2.0.36" (file-symlink-p "/leo＠localhost:/vmlinuz") => "boot/vmlinuz-2.0.36" (file-regular-p "/vmlinuz") => t

1 participants
0 comments

XEmacs 21.0.63 on AIX 4.3.1??? 25 years, 2 months

Derek Scherger

Ooops, I previously posted this to the xemacs list, perhaps this is a better place for it! I've just tried to build and run XEmacs 21.0.63 on an RS/6000 recently upgraged to AIX 4.3.1 and it seems to be somewhat broken. I did notice that there were lots of notes on the mailing lists about XEmacs 20.4 having problems on AIX 4.3.1 and have experienced them myself. I was hoping that the newer 21.xx sources might have the problems fixed. Anyhow, the build seemed to work fine but the executable now has problems during startup and prints the following: $ src/xemacs Fatal error: assertion failed, file EmacsFrame.c, line 383, RECORD_TYPEP (frame, lrecord_frame) || MARKED_RECORD_P (frame) Fatal error (6). <snip> Lisp backtrace follows: # bind (frame-being-created) make-frame(nil #<x-device on "199.185.100.61:0.0" 0x70c>) frame-initialize() # bind (debugger debug-on-error command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) IOT/Abort trap (core dumped) $ I tried gdb on the core file but it doesn't seem to like it: xemacs-21.0.63/core" is not a core dump: File format not recognized This problem looks *really* similar to the problems I had trying to get 20.4 to run on the same machine under AIX 4.3.1, although the filename has changed. Note that the List backtrace is identical! Here's the first line of the message from XEmacs 20.4: Fatal error: assertion failed, file specifier.c, line 2345, abort() It seems somehow to be X related... I'm hoping this is a local configuration problem! Can anyone help? Thanks much! -- Cheers, Derek _____________________________________________________________________ Derek Scherger Echologic Software Corporation mailto:derek＠echologic.com http://www.echologic.com

1 participants
0 comments

Lisp shadow in xemacs-sumo-1999-02-02.tar.gz 25 years, 2 months

Paul Keusemann

I don't know if this particularly import but, I found this while building 21.0.63... Testing for Lisp shadows ... This site has duplicate Lisp libraries with the same name. If a locally-installed Lisp library overrides a library in the Emacs release, that can cause trouble, and you should probably remove the locally-installed version unless you know what you are doing. /usr2/paulk/coronafs9/lib/xemacs/xemacs-packages/lisp/gnus/pop3 hides /usr2/paulk/coronafs9/lib/xemacs/xemacs-packages/lisp/mail-lib/pop3 1 Emacs Lisp load-path shadowing was found /usr2/paulk/coronfs9/lib/xemacs is a fresh install from xemacs-sumo-1999-02-02.tar.gz -- Paul Keusemann pkeusem(a)visi.com 4266 Joppa Court (612) 894-7805 Savage, MN 55378

1 participants
0 comments

Re: rssh.el interactions with ange-ftp/efs 25 years, 2 months

Kai Großjohann

Sandy Rutherford <sandy(a)math.ubc.ca> writes: > Therefore, the main reason for supporting URLs is not to allow people > to use rcp, scp, etc, but to provide the convenience of having EFS > support a widespread syntax. Support for URLs will not lead to > support for rcp, scp, etc. Well, the current syntax for remote file names does not allow one to specify a protocol, it just assumes FTP. Changing the file name syntax in some way such that it allows one to specify a protocol is a Good Thing, IMHO. The new syntax does not have to be the URL syntax, but I've got to admit that URL syntax kinds of suggests itself. People suggest to use URL syntax because it can be construed as a standard for naming remote files. As an alternative, one could use /user＠host:/path/to/file for generic remote file names /protocol:user＠host:/path/to/file for specifying a protocol This alternative would be a rather natural extension of the existing syntax, I think. To answer the last sentence cited above: the support for URLs is not a _s_u_f_f_i_c_i_e_n_t condition for supporting several protocols, but the ability to specify a protocol is a _n_e_c_e_s_s_a_r_y condition for supporting several protocols. kai -- I like _b_o_t_h kinds of music.

1 participants
0 comments

tetris crashes XEmacs 21.2 on NT 25 years, 2 months

Gleb Arshinov

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 "Artemis" [Lucid] (i586-pc-win32) of Mon Feb 01 1999 on SLOTH configured using `configure UNKNOWN' Here's a backtrace: _stricmp + 35 bytes xpm_to_eimage(long 0x01f55880, unsigned char * 0x0082dfe8, unsigned char * * 0x0082e1fc, int * 0x0082e224, int * 0x0082e1f8, int * 0x0082e22c, int * 0x0082e20c, int * 0x0082e1ec, color_symbol * 0x01f858a0, int 0x00000003) line 798 + 24 bytes mswindows_xpm_instantiate(long 0x01f55880, long 0x81f85e20, long 0xa1b04804, long 0xa1b04804, int 0x0000006f, long 0x01c8f600) line 880 + 45 bytes instantiate_image_instantiator(long 0x01c49600, long 0x01c8f600, long 0x81f85e20, long 0xa1b04804, long 0xa1b04804, int 0x0000006f) line 565 + 51 bytes image_instantiate(long 0x01f55900, long 0x01284920, long 0x01c8f600, long 0x81f85e20, long 0x20000001) line 2463 + 29 bytes call_with_suspended_errors_1(long 0x01ce9d80) line 2057 + 256 bytes internal_catch(long 0x01b07740, long (long)* 0x01056ec0 call_with_suspended_errors_1(long), long 0x01ce9d80, int * 0x0082e3b4) line 1315 + 7 bytes call_with_suspended_errors(long (void)* 0x010a1120 image_instantiate(long, long, long, long, long), volatile long 0x01284920, long 0xa1b04804, _error_behavior_struct_ {...}, int 0x00000005) line 2170 + 28 bytes specifier_instance_from_inst_list(long 0x01f55900, long 0x01284920, long 0x01c8f600, long 0x41f368f4, _error_behavior_struct_ {...}, int 0x00000001, long 0x20000001) line 2393 + 54 bytes specifier_instance(long 0x01f55900, long 0x01284920, long 0x01c8f600, _error_behavior_struct_ {...}, int 0x00000001, int 0x00000000, long 0x20000001) line 2505 + 64 bytes glyph_image_instance(long 0x01fb1880, long 0x01c8f600, _error_behavior_struct_ {...}, int 0x00000001) line 3184 + 35 bytes glyph_height_internal(long 0x01fb1880, long 0xa1b04804, unsigned int 0x00000000, long 0x01c8f600, int 0x00000002) line 3198 + 22 bytes glyph_height(long 0x01fb1880, long 0xa1b04804, unsigned int 0x00000000, long 0x01c8f600) line 3288 + 23 bytes Fglyph_height(long 0x01fb1880, long 0x01c8f600) line 3328 + 21 bytes Ffuncall(int 0x00000002, long * 0x0082e690) line 3189 + 107 bytes execute_optimized_program(unsigned char * 0x01fac418, int 0x00000004, long * 0x01f67984) line 754 + 16 bytes funcall_compiled_function(long 0x01f87138, int 0x00000000, long * 0x0082e978) line 530 + 53 bytes Ffuncall(int 0x00000001, long * 0x0082e974) line 3221 + 17 bytes execute_optimized_program(unsigned char * 0x01f55b18, int 0x00000004, long * 0x01f67804) line 754 + 16 bytes funcall_compiled_function(long 0x01f87154, int 0x00000000, long * 0x0082ec5c) line 530 + 53 bytes Ffuncall(int 0x00000001, long * 0x0082ec58) line 3221 + 17 bytes execute_optimized_program(unsigned char * 0x01fb1a58, int 0x00000002, long * 0x01f77444) line 754 + 16 bytes funcall_compiled_function(long 0x01f871fc, int 0x00000001, long * 0x0082ef38) line 530 + 53 bytes Ffuncall(int 0x00000002, long * 0x0082ef34) line 3221 + 17 bytes execute_optimized_program(unsigned char * 0x01f55b98, int 0x00000005, long * 0x01f55c84) line 754 + 16 bytes funcall_compiled_function(long 0x01f875d0, int 0x00000000, long * 0x0082f220) line 530 + 53 bytes Ffuncall(int 0x00000001, long * 0x0082f21c) line 3221 + 17 bytes execute_optimized_program(unsigned char * 0x01fb1b18, int 0x00000002, long * 0x01f85fc4) line 754 + 16 bytes funcall_compiled_function(long 0x01f875ec, int 0x00000000, long * 0x0082f518) line 530 + 53 bytes Ffuncall(int 0x00000001, long * 0x0082f514) line 3221 + 17 bytes apply1(long 0x01f875ec, long 0xa1b04804) line 3803 + 11 bytes Fcall_interactively(long 0xa1bf99e4, long 0xa1b0481c, long 0xa1b04804) line 397 + 13 bytes Fcommand_execute(long 0xa1bf99e4, long 0xa1b0481c, long 0xa1b04804) line 2623 + 17 bytes Ffuncall(int 0x00000003, long * 0x0082f76c) line 3189 + 141 bytes execute_optimized_program(unsigned char * 0x011bcb98, int 0x00000008, long * 0x011bca6c) line 754 + 16 bytes funcall_compiled_function(long 0x011bca2c, int 0x00000001, long * 0x0082fa60) line 530 + 53 bytes Ffuncall(int 0x00000002, long * 0x0082fa5c) line 3221 + 17 bytes Fcall_interactively(long 0xa1b9146c, long 0xa1b04804, long 0xa1b04804) line 949 + 22 bytes Fcommand_execute(long 0xa1b9146c, long 0xa1b04804, long 0xa1b04804) line 2623 + 17 bytes execute_command_event(command_builder * 0x01b72ec0, long 0x01c7ea6c) line 4345 + 25 bytes Fdispatch_event(long 0x01c7ea6c) line 4644 + 71 bytes Fcommand_loop_1() line 578 + 9 bytes command_loop_1(long 0xa1b04804) line 494 condition_case_1(long 0xa1b04864, long (long)* 0x0103a918 command_loop_1(long), long 0xa1b04804, long (long, long)* 0x0103a3c3 cmd_error(long, long), long 0xa1b04804) line 1640 + 7 bytes command_loop_3() line 255 + 35 bytes command_loop_2(long 0xa1b04804) line 267 internal_catch(long 0xa1b1f864, long (long)* 0x0103a513 command_loop_2(long), long 0xa1b04804, int * 0x00000000) line 1315 + 7 bytes initial_command_loop(long 0xa1b04804) line 304 + 26 bytes STACK_TRACE_EYE_CATCHER(int 0x00000001, char * * 0x01c11c80, char * * 0x01bf1700, int 0x00000000) line 1736 + 9 bytes main(int 0x00000001, char * * 0x01c11c80, char * * 0x01bf1700) line 2165 + 21 bytes mainCRTStartup + 211 bytes _start() line 165 KERNEL Recent keystrokes: M-x C-g misc-user Recent messages (most recent first): Parsing c:\home\gleb\.mailrc... Loading emacsbug...done Quit Loading emacsbug... Loading tinylib...done Loading tinylib... tinylibm: ** internal info: Custom [t] declare [t] Loading c:\home\gleb\.xemacs_custom...done Loading lazy-shot...done Loading lazy-shot...

1 participants
0 comments

make-frame-on-display weirdness 25 years, 2 months

Glynn Clements

If I start another X server on :1, then use M-x make-frame-on-display RET :1 RET the new frame's menubar is blank. -- Glynn Clements <glynn(a)sensei.co.uk>

1 participants
0 comments

Re: rssh.el interactions with ange-ftp/efs 25 years, 2 months

Kai Großjohann

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Kai" == Kai Grossjohann <Kai.Grossjohann(a)CS.Uni-Dortmund.DE> writes: > > Kai> Why do we have to use URL syntax if it is inconvenient? > Kai> Wouldn't "/ftp:user＠host:/path/to/file" work, too? > > Specifically, it doesn't generalize very well to relative URLs with > non-default port numbers. There is no such thing as a relative URL with a non-default port number. Please note that all URLs starting with "http:" are absolute even though Netscape accepts strange ones like "http:file" meaning the same thing as "file". (The RFCs I read a year or so ago required "http:" to be followed by "//".) But I agree that port numbers should be allowed. Btw, I'd say that one uses "/nihp:user＠host:/path/to/file" for the Not Invented Here Protocol. kai -- Abort this operation? [Abort] [Cancel]

3 participants
2 comments

Re: rssh.el interactions with ange-ftp/efs 25 years, 2 months

Jan Vroonhof

Matt Curtin <cmcurtin(a)interhack.net> writes: > If I am understanding you properly, then, the issue is: > > How do we add cryptographic functionality to Emacs without > removing the impetus to create a free SSH-like tool? No, :-(. The issue is How do we extend the remote file hooks/syntax in Emacs such that is allows access mechanisms other than FTP. Where other includes for example: 1. Http. Free tools exist. Even pure elisp implementations. 2. rsh like. Free tools exist, i.e. rsh. Yes, there are also non-free remote file protocols, but that should be irrelevant[1]. Jan Footnotes: [1] Nobody is going to seriously propose (if (string-match "ssh" rrsh-rsh-program) (error "Go away!)) hopefully?

4 participants
6 comments

Bad texi - files 25 years, 2 months

Enrico Scholz

Hi, newer makeinfo (>=3.12c) _requires_ a "." or "," after a ＠xref so a lot of the .texi - files failes to compile. A patch correcting the files is appended. Enrico -- eMail: enrico.scholz(a)wirtschaft.tu-chemnitz.de talk: ensc(a)ultra.csn.tu-chemnitz.de

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta February 1999