From kai at cmail.ru Mon Jul 1 10:18:00 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Mon, 1 Jul 2002 13:18:00 +0300 Subject: Things to do before 4.6.0 In-Reply-To: References: <20020627192828.GA3141@oskar> Message-ID: <20020701131800.B520@it.efp.com.ua> Hi, Oskar and Pavel! > > > > 4) Compressed tarballs produced by "tar cz" with older versions of GNU tar > > > (i.e. those with padding at the end) cannot be opened by pressing Enter > > > ("doesn't look like a tar archive") > > > > Can someone provide an example tarball? > > Attached (test.tgz) This problem is in vfs/sfs.c/vfmake(). Now it calls my_system and returns -1 if return code of my_system is not 0. Well, gzip returns 2 for this test.tgz: test.tgz: decompression OK, trailing garbage ignored and vfmake returns -1 (error), and then sfs.c/redirect() return "/I_MUST_NOT_EXIST" and so sfs_open fails. The same thing is happen if .tgz is not downloaded fully. As for me vfmake should read stderr and return this string to higher lever, and so user can decide what to do with this file. -- Regards, Andrew V. Samoilov. From kai at cmail.ru Mon Jul 1 13:58:23 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Mon, 1 Jul 2002 16:58:23 +0300 Subject: Fix for possible crashes in src/utilunix.c Message-ID: <20020701165823.A245@it.efp.com.ua> Hi, Pavel! This patch fixes 2 possible buffer overflows in the mc. Test case: 1. Be sure there is no %d file in the current directory. 2. Type M-! 3. Type "gzip %d" and press Enter. '%s' can crash your mc. P.S. Please commit this patch, I have not access to cvs now. src/ChangeLog: * utilunix.c (close_error_pipe): Use "%s" in message () to prevent possible crash. (check_error_pipe): Likewise. --- src/utilunix.c Tue Mar 19 17:36:45 2002 +++ src/utilunix.c Mon Jul 1 16:37:53 2002 @@ -401,7 +401,7 @@ close_error_pipe (int error, char *text) if (len == 0) return 0; /* Nothing to show */ /* Show message from pipe */ - message (error, title, msg); + message (error, title, "%s", msg); } else { /* Show given text and possible message from pipe */ message (error, title, " %s \n %s ", text, msg); @@ -435,9 +435,9 @@ void check_error_pipe (void) close (error_pipe[0]); } if (len > 0) - message (0, _(" Warning "), error); + message (0, _(" Warning "), "%s", error); } -#endif +#endif /* !VFS_STANDALONE */ static struct sigaction ignore, save_intr, save_quit, save_stop; From sasha at k806.mainet.msk.su Tue Jul 2 13:50:31 2002 From: sasha at k806.mainet.msk.su (Alexander Valentinovich Smirnoff) Date: Tue, 2 Jul 2002 17:50:31 +0400 Subject: Little change Message-ID: <004c01c221cf$6ea83720$3a06080a@NIS806.local.net> See small change in MC-4.5.55 for compatibility with Z-Shell-4.1.0-dev-1 in attached file. -------------- next part -------------- A non-text attachment was scrubbed... Name: subshell.c Type: application/octet-stream Size: 36057 bytes Desc: not available URL: From proski at gnu.org Tue Jul 2 16:46:03 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 2 Jul 2002 12:46:03 -0400 (EDT) Subject: Things to do before 4.6.0 In-Reply-To: <20020701131800.B520@it.efp.com.ua> Message-ID: Hi, Andrew! > > > > 4) Compressed tarballs produced by "tar cz" with older versions of GNU tar > > > > (i.e. those with padding at the end) cannot be opened by pressing Enter > > > > ("doesn't look like a tar archive") > > > > > > Can someone provide an example tarball? > > > > Attached (test.tgz) > > This problem is in vfs/sfs.c/vfmake(). > Now it calls my_system and returns -1 if > return code of my_system is not 0. > > Well, gzip returns 2 for this test.tgz: However, it returns 0 with the "-f" (force) flag: > > test.tgz: decompression OK, trailing garbage ignored Not with gzip-1.3. In fact, debugging shows that mc never enters vfmake() and never runs gzip. The problem is with is_gunzipable() in src/util.c. It reads the uncompressed size at the end, and test.tgz has zeroes there. -- Regards, Pavel Roskin From sasha at k806.mainet.msk.su Tue Jul 2 16:23:29 2002 From: sasha at k806.mainet.msk.su (Alexander Valentinovich Smirnoff) Date: Tue, 2 Jul 2002 20:23:29 +0400 Subject: Small change Message-ID: <00b001c221e4$cd160e30$3a06080a@NIS806.local.net> -------------- next part -------------- A non-text attachment was scrubbed... Name: ext.c Type: application/octet-stream Size: 20019 bytes Desc: not available URL: From proski at gnu.org Tue Jul 2 21:36:37 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 2 Jul 2002 17:36:37 -0400 (EDT) Subject: Things to do before 4.6.0 In-Reply-To: Message-ID: > Not with gzip-1.3. In fact, debugging shows that mc never enters vfmake() > and never runs gzip. The problem is with is_gunzipable() in src/util.c. > It reads the uncompressed size at the end, and test.tgz has zeroes there. is_gunzipable() has been completely rewritten and renamed to get_compression_type(). It doesn't try to determine the uncompressed size anymore - the size was only used as the indicator whether the file is compressed or not. The fix has been committed. -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 06:56:09 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 02:56:09 -0400 (EDT) Subject: Shell exit from viewer and editor fixed Message-ID: Hello! The bug with MC hanging with 100% CPU utilization on exit from shell while in internal editor of viewer has been fixed. The fix is two-fold. view_other_cmd() shuts down all extra channels for select() in get_event(), just like edition_pre_exec(). view_other_cmd() and edition_{pre,post}_exec() should be more similar now, which will enable some code sharing between them. When the shell exists, the channels are not restored. This prevents get_event() from waiting on closed channels. quit_cmd_internal() now stops not only the top-level dialog, but also the current dialog if it exists. This causes a fast exit from both dialogs without waiting for any more events. The bug with 100% CPU utilization on "TMOUT=1 mc" is not fixed yet. The real fix probably belongs to get_event(), which should check error conditions and maybe respect the "quit" variable. Alternatively, the SIGCHLD handler for subshell should unregister the select() channel for the subshell. -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 07:21:43 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 03:21:43 -0400 (EDT) Subject: Small change In-Reply-To: <00b001c221e4$cd160e30$3a06080a@NIS806.local.net> Message-ID: Hello! Could you please post patches and comments for them instead of posting whole files? -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 07:26:35 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 03:26:35 -0400 (EDT) Subject: Small problem In-Reply-To: <000001c22072$6eeaaff0$0200a8c0@attbi.com> Message-ID: Hi, Scott! > I have pulled the latest CVS of Midnight Commander. I have tried to > run the autogen.sh to make the configure utility, and it complains that > it cannot find a file called aclocal. Is this file supposed to be > created by autoconf? This is on FreeBSD 4.5, and is with a clean, fresh > CVS pull of MC. I've just committed file README.CVS, which should answer all your questions. If it doesn't, or it doesn't work for you, please write to the list. You can always try the development snapshot from www.midnightcommander.org if you don't want to install all those tools. -- Regards, Pavel Roskin From kai at cmail.ru Wed Jul 3 12:46:05 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 3 Jul 2002 15:46:05 +0300 Subject: Patch to improve MAD subsystem Message-ID: <20020703154605.A1395@it.efp.com.ua> Hi! This patch improves MAD subsystem, so it is possible now to see where are g_strconcat, g_strdup_printf or g_strdup_vprintf were called. ChangeLog: * mad.[ch] [__GNUC__] (mad_strconcat): Use macro varargs. (mad_strdup_printf): Likewise. (mad_strdup_vprintf): Likewise. * main.c [HAVE_MAD] (main): Release this_dir and other_dir. --- src/mad.h Fri Dec 28 03:11:52 2001 +++ src/mad.h Thu Jun 20 15:27:35 2002 @@ -67,9 +67,18 @@ #define g_strdup(x) mad_strdup (x, __FILE__, __LINE__) #define g_strndup(x, n) mad_strndup (x, n, __FILE__, __LINE__) #define g_free(x) mad_free (x, __FILE__, __LINE__) +#ifndef __GNUC__ #define g_strconcat mad_strconcat #define g_strdup_printf mad_strdup_printf #define g_strdup_vprintf mad_strdup_vprintf +#else +#define g_strconcat(first, argc...) \ + mad_strconcat (__FILE__, __LINE__, first, ## argc) +#define g_strdup_printf(format, argc...) \ + mad_strdup_printf(__FILE__, __LINE__, format, ## argc) +#define g_strdup_vprintf(format, argc...) \ + mad_strdup_vprintf (__FILE__, __LINE__, format, ## argc) +#endif #define g_get_current_dir() mad_get_current_dir (__FILE__, __LINE__) #endif /* MAD_GLIB */ @@ -84,9 +93,16 @@ char *mad_strndup (const char *s, int n, void mad_free (void *ptr, const char *file, int line); void mad_finalize (const char *file, int line); char *mad_tempnam (char *s1, char *s2, const char *file, int line); +#ifndef __GNUC__ char *mad_strconcat (const char *first, ...); char *mad_strdup_printf (const char *format, ...); char *mad_strdup_vprintf (const char *format, va_list args); +#else +char *mad_strconcat (const char *file, int line, const char *first, ...); +char *mad_strdup_printf (const char *file, int line, const char *format, ...) + __attribute__ ((format (printf, 3, 4))); +char *mad_strdup_vprintf (const char *file, int line, const char *format, va_list args); +#endif char *mad_get_current_dir (const char *file, int line); #else --- src/mad.c Sat Jun 1 23:55:58 2002 +++ src/mad.c Wed Jul 3 15:08:33 2002 @@ -39,6 +39,9 @@ #undef g_strndup #undef g_free #undef g_get_current_dir +#undef g_strconcat +#undef g_strdup_printf +#undef g_strdup_vprintf #include #include @@ -346,8 +349,16 @@ void mad_finalize (const char *file, int } char * +#ifndef __GNUC__ mad_strconcat (const char *first, ...) +#else +mad_strconcat (const char *file, int line, const char *first, ...) +#endif { +#ifndef __GNUC__ + const char *file = "(mad_strconcat)"; + int line = 0; +#endif va_list ap; long len; char *data, *result; @@ -361,7 +372,7 @@ mad_strconcat (const char *first, ...) while ((data = va_arg (ap, char *)) != 0) len += strlen (data); - result = mad_alloc(len, "(mad_strconcat)", 0); + result = mad_alloc(len, file, line); va_end (ap); @@ -379,14 +390,22 @@ mad_strconcat (const char *first, ...) /* These two functions grabbed from GLib's gstrfuncs.c */ char* +#ifndef __GNUC__ mad_strdup_vprintf (const char *format, va_list args1) +#else +mad_strdup_vprintf (const char *file, int line, const char *format, va_list args1) +#endif { +#ifndef __GNUC__ + const char *file = "(mad_strdup_vprintf)"; + int line = 0; +#endif char *buffer; va_list args2; G_VA_COPY (args2, args1); - buffer = mad_alloc(g_printf_string_upper_bound(format, args1), "(mad_strdup_vprintf)", 0); + buffer = mad_alloc(g_printf_string_upper_bound(format, args1), file, line); vsprintf (buffer, format, args2); va_end (args2); @@ -395,13 +414,21 @@ mad_strdup_vprintf (const char *format, } char* +#ifndef __GNUC__ mad_strdup_printf (const char *format, ...) +#else +mad_strdup_printf (const char *file, int line, const char *format, ...) +#endif { char *buffer; va_list args; va_start (args, format); +#ifdef __GNUC__ + buffer = mad_strdup_vprintf(file, line, format, args); +#else buffer = mad_strdup_vprintf(format, args); +#endif va_end (args); return buffer; --- src/main.c Thu Jun 6 14:33:51 2002 +++ src/main.c Wed Jul 3 09:19:40 2002 @@ -2777,6 +2791,10 @@ main (int argc, char *argv []) #ifdef HAVE_CHARSET free_codepages_list (); #endif + if (this_dir) + g_free (this_dir); + if (other_dir) + g_free (other_dir); #endif mad_finalize (__FILE__, __LINE__); From kai at cmail.ru Wed Jul 3 12:52:14 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 3 Jul 2002 15:52:14 +0300 Subject: cpio.c:138: warning: `type' might be used uninitialized in this function Message-ID: <20020703155214.A1415@it.efp.com.ua> Hi! Can somebody apply this patch? ChangeLog: * cpio.c (cpio_open_cpio_file): Fix type initialization. --- vfs/cpio.c Wed Jul 3 06:03:52 2002 +++ vfs/cpio.c Wed Jul 3 15:40:39 2002 @@ -149,7 +149,7 @@ static int cpio_open_cpio_file(vfs *me, mc_stat(name, &(super->u.cpio.stat)); super->u.cpio.type = CPIO_UNKNOWN; - if (get_compression_type(fd) != COMPRESSION_NONE) { + if ((type = get_compression_type(fd)) != COMPRESSION_NONE) { char *s; mc_close(fd); From proski at gnu.org Wed Jul 3 13:16:10 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 09:16:10 -0400 (EDT) Subject: cpio.c:138: warning: `type' might be used uninitialized in this function In-Reply-To: <20020703155214.A1415@it.efp.com.ua> Message-ID: > Can somebody apply this patch? Done. Thanks. -- Regards, Pavel Roskin From kai at cmail.ru Wed Jul 3 14:03:36 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 3 Jul 2002 17:03:36 +0300 Subject: Memory leakins in sfs.c Message-ID: <20020703170335.A3745@it.efp.com.ua> Hi! Can somebody apply this patch? ChangeLog: 2002-07-03 Andrew V. Samoilov * sfs.c (sfs_free): Fix memory leakings. (sfs_init): Use PATH_SEP_STR. --- vfs/sfs.c Tue Oct 2 11:06:37 2001 +++ vfs/sfs.c Wed Jul 3 16:50:39 2002 @@ -259,6 +259,10 @@ static void sfs_free (vfsid id) prev->next = cur->next; else head = cur->next; + + g_free (cur->cache); + g_free (cur->name); + g_free (cur); } static void sfs_fill_names (vfs *me, void (*func)(char *)) @@ -295,7 +299,7 @@ static int sfs_init (vfs *me) char *mc_sfsini; FILE *cfg; - mc_sfsini = concat_dir_and_file (mc_home, "extfs/sfs.ini"); + mc_sfsini = concat_dir_and_file (mc_home, "extfs" PATH_SEP_STR "sfs.ini"); cfg = fopen (mc_sfsini, "r"); if (!cfg){ From kai at cmail.ru Wed Jul 3 15:05:30 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 3 Jul 2002 18:05:30 +0300 Subject: Fix for extfs_fill_names Message-ID: <20020703180530.A4214@efp.com.ua> Hi, this patch fix filename generation in extfs_fill_names. Now it will be possible to type C-x a and descent to extfs archives from this menu. ChangeLog: * extfs.c (extfs_fill_names): Generate filename#patchfs/dir instead of #patchfs/filename/dir. Use PATH_SEP_STR. --- vfs/extfs.c Wed Feb 20 08:15:58 2002 +++ vfs/extfs.c Wed Jul 3 17:56:00 2002 @@ -101,9 +101,9 @@ static void extfs_fill_names (vfs *me, v char *name; while (a){ - name = g_strconcat (extfs_prefixes [a->fstype], "#", - (a->name ? a->name : ""), "/", - a->current_dir->name, NULL); + name = g_strconcat (a->name ? a->name : "", + "#", extfs_prefixes [a->fstype], + PATH_SEP_STR, a->current_dir->name, NULL); (*func)(name); g_free (name); a = a->next; From proski at gnu.org Wed Jul 3 15:31:12 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 11:31:12 -0400 (EDT) Subject: Memory leakins in sfs.c In-Reply-To: <20020703170335.A3745@it.efp.com.ua> Message-ID: > * sfs.c (sfs_free): Fix memory leakings. > (sfs_init): Use PATH_SEP_STR. Applied. Thanks! -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 15:57:42 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 11:57:42 -0400 (EDT) Subject: Fix for extfs_fill_names In-Reply-To: <20020703180530.A4214@efp.com.ua> Message-ID: > this patch fix filename generation in extfs_fill_names. > Now it will be possible to type C-x a and descent to extfs > archives from this menu. Great! Applied. -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 16:18:28 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 12:18:28 -0400 (EDT) Subject: Patch to improve MAD subsystem In-Reply-To: <20020703154605.A1395@it.efp.com.ua> Message-ID: On Wed, 3 Jul 2002, Andrew V. Samoilov wrote: > Hi! > > This patch improves MAD subsystem, so it is possible now to > see where are g_strconcat, g_strdup_printf or g_strdup_vprintf > were called. Applied. Thanks. -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 16:41:21 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 12:41:21 -0400 (EDT) Subject: bug - tmout hang mc In-Reply-To: <20020416120926.GA21959@atos.wmid.amu.edu.pl> Message-ID: Hi, Andrzej! > when shell is bash, and variable TMOUT is set in ex 300 (after 300sec it > off) and i run mc, after 300s mc hang. It take 100% cpu power:) > Could You look at it? Fixed in CVS: =========================== --- ChangeLog +++ ChangeLog @@ -1 +1,6 @@ +2002-07-03 Pavel Roskin + + * subshell.c (sigchld_handler): Remove subshell_pty from the + channel list if the subshell has died. + 2002-07-03 Andrew V. Samoilov --- subshell.c +++ subshell.c @@ -912,6 +912,7 @@ void sigchld_handler (int sig) # endif { subshell_alive = FALSE; + delete_select_channel (subshell_pty); if (WIFEXITED (status) && WEXITSTATUS (status) != FORK_FAILURE) quit |= SUBSHELL_EXIT; /* Exited normally */ } =========================== -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 17:13:29 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 13:13:29 -0400 (EDT) Subject: Small change (ext.c) In-Reply-To: <00b001c221e4$cd160e30$3a06080a@NIS806.local.net> Message-ID: Hello! Making the patch from your ext.c file (next time do it yourself, please): ========================== diff -ur old/ext.c new/ext.c --- old/ext.c Mon Aug 13 20:55:38 2001 +++ new/ext.c Wed Jul 3 13:06:54 2002 @@ -153,7 +153,10 @@ return; } cmd_file = fdopen (cmd_file_fd, "w"); - fputs ("#!/bin/sh\n", cmd_file); + /* Disabled by Alexander Valentinovich Smirnoff + + Better to use default shell for this! */ + /* fputs ("#!/bin/sh\n", cmd_file);*/ prompt [0] = 0; for (;*data && *data != '\n'; data++){ ========================== Wrong. Many commands are written specifically for Bourne shell syntax. Using the user's shell is going to break things, especially if it's tsch (have you considered this possibility at all?), but zsh is also not 100% compatible with sh. -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 17:18:10 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 13:18:10 -0400 (EDT) Subject: Little change In-Reply-To: <004c01c221cf$6ea83720$3a06080a@NIS806.local.net> Message-ID: Hello! > See small change in MC-4.5.55 for compatibility with Z-Shell-4.1.0-dev-1 > in attached file. ========================= diff -ur old/subshell.c new/subshell.c --- old/subshell.c Fri Aug 24 00:51:11 2001 +++ new/subshell.c Wed Jul 3 13:06:48 2002 @@ -338,7 +338,13 @@ * (Debian-mc-maintainer) from a patch from * Radovan Garabik */ - execl (shell, "zsh", "-Z", NULL); + /* execl (shell, "zsh", "-Z", NULL); */ + /* Changed by Alexander Valentinovich Smirnoff + + for compatibility with Z-Shell version 4.1.0-dev-1 + Flag "-Z" deleted, because it is in on by default + */ + execl (shell, "zsh", "-i", NULL); break; } ========================= As far as I know, -Z (enable line editor) is not default on some OSes. I'm not aware of any reasons to use "-i" explicitly. By the way, the comments should not be about what has been changed, they shoud describe what the code currently does. Developers working on this code after you should not normally have to look at the old code just to understand your comment. -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 19:50:52 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 15:50:52 -0400 (EDT) Subject: Compiler warnings on SunOS In-Reply-To: <200206121241.g5CCfnc6019545@rzdspc5.informatik.uni-hamburg.de> Message-ID: Hi, Roland! > compiling mc-4.55 on SunOS raises some compiler warnings. You might want to > avoid them. I know about those warnings. The problem is that most of them either happen in the files that come from other projects (gettext, popt), or cannot be fixed without introducing extra complexity (e.g. casts). The only exception is using signed char with the function like isspace(). It seems that the standard requires unsigned char to be used with such functions. This will be fixed. > loadmsgcat.c: In function `_nl_load_domain': > loadmsgcat.c:510: warning: subscript has type `char' Files from gettext. The fix is in gettext-0.11.2, but it's not likely to be used in the next release of MC. > direntry.c: In function `vfs_s_dump': > direntry.c:1015: warning: int format, long int arg (arg 4) mode_t is unsigned int in glibc. No easy fix. > tar.c: In function `from_oct': > tar.c:43: warning: subscript has type `char' > tar.c:54: warning: subscript has type `char' > ftpfs.c: In function `setup_passive': > ftpfs.c:873: warning: subscript has type `char' > ftpfs.c:877: warning: subscript has type `char' Fixed in MC CVS right now. > util.c: In function `size_trunc_sep': > util.c:294: warning: subscript has type `char' > util.c: In function `skip_numbers': > util.c:829: warning: subscript has type `char' Fixed. > screen.c: In function `string_file_perm_octal': > screen.c:312: warning: unsigned int format, mode_t arg (arg 4) > screen.c: In function `string_file_nlinks': > screen.c:322: warning: int format, long int arg (arg 4) > screen.c: In function `string_file_nuid': > screen.c:342: warning: int format, uid_t arg (arg 4) > screen.c: In function `string_file_ngid': > screen.c:352: warning: int format, gid_t arg (arg 4) These are int in glibc. > In file included from key.c:48: > /usr/openwin/include/X11/Xlib.h:32: warning: ignoring pragma: "@(#)Xlib.h > 1.10 00/10/12 SMI This is not in MC. > file.c: In function `do_transform_source': > file.c:210: warning: subscript has type `char' > find.c: In function `search_content': > find.c:427: warning: subscript has type `char' > user.c: In function `expand_format': > user.c:189: warning: subscript has type `char' > user.c: In function `execute_menu_command': > user.c:601: warning: subscript has type `char' > user.c:603: warning: subscript has type `char' Fixed. > subshell.c: In function `init_subshell': > subshell.c:436: warning: int format, pid_t arg (arg 4) > subshell.c: In function `exit_subshell': > subshell.c:780: warning: int format, pid_t arg (arg 4) > main.c: In function `OS_Setup': > main.c:2390: warning: int format, pid_t arg (arg 4) No easy fix. > main.c: In function `handle_args': > main.c:2878: warning: subscript has type `char' Fixed. > poptparse.c: In function `poptParseArgvString': > poptparse.c:48: warning: subscript has type `char' This is from popt, and even the latest popt from rpm-4.0.4 doesn't fix it. > charsets.c: In function `translate_character': > charsets.c:116: warning: passing arg 2 of `iconv' from incompatible pointer > type What's the declaration of iconv() on your system? glibc-2.2.4 expects char** at the second argument. > That's all. It's just because I like programs that compile without any > warnings ... Me too :-) -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 3 21:11:22 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Jul 2002 17:11:22 -0400 (EDT) Subject: subshell on AIX In-Reply-To: Message-ID: Hello, Alexander! > I think this problem was introduced while moving to autoconfig : the > subshell code itself is ok, the problem is that wrong platform specific code > is selected by #ifdef's. > Please apply my patch, there are still some poor souls around who have to > work on AIX :) MC tries to use /dev/ptmx whenever grantpt() function is present. I understand it doesn't work on AIX, so you want to fallback to the BSD style pseudoterminals. It may happen that some newer versions of AIX will have working /dev/ptmx, and forcing them to use the legacy API just because their system is called AIX and had a problem in the past would be wrong. It would be better if you compiled MC without your patch and debugged pty_open_master() to see where it fails. Then maybe it would be possible to detect this problem in the configure script. -- Regards, Pavel Roskin From avarakin00 at hotmail.com Thu Jul 4 02:36:58 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Wed, 3 Jul 2002 22:36:58 -0400 Subject: subshell on AIX References: Message-ID: Hi Pavel, > It may happen that some newer versions of AIX will have working /dev/ptmx, > and forcing them to use the legacy API just because their system is called > AIX and had a problem in the past would be wrong. I tested mc without my patch on both AIX 4.3.3 patch level 9 and AIX 5L (which is the latest), and subshell doesn't work on both. It also looks like AIX 4.3.3 will be around for quite a while, se we have to support it as well. Thus I believe we must use this legacy interface. > It would be better if you compiled MC without your patch and debugged > pty_open_master() to see where it fails. Then maybe it would be possible > to detect this problem in the configure script. This is exactly how I found the problem! It fails while trying to open pty device, which just doesn't exist on AIX. I agree that better place to fix the problem is in configure script, but I don't know how to do that, and I also don't have all those GNU auto config utilities on my AIX boxes. I also think that we can break some other platform this way. One other option is to use some kind of runtime detection of the pty system which is present, but I am afraid it may also break some other platform. So I think the safest and easiest fix is using "#ifdef AIX" approach, which is exactly what my patch does. Alex ----- Original Message ----- From: "Pavel Roskin" To: "Alexander Varakin" Cc: Sent: Wednesday, July 03, 2002 5:11 PM Subject: Re: subshell on AIX > Hello, Alexander! > > > I think this problem was introduced while moving to autoconfig : the > > subshell code itself is ok, the problem is that wrong platform specific code > > is selected by #ifdef's. > > Please apply my patch, there are still some poor souls around who have to > > work on AIX :) > > MC tries to use /dev/ptmx whenever grantpt() function is present. I > understand it doesn't work on AIX, so you want to fallback to the BSD > style pseudoterminals. > > > > -- > Regards, > Pavel Roskin > From kai at cmail.ru Thu Jul 4 09:25:46 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Thu, 04 Jul 2002 12:25:46 +0300 Subject: Compiler warnings on SunOS References: Message-ID: <3D24149A.9040809@cmail.ru> Pavel Roskin wrote: >Hi, Roland! > > > >>compiling mc-4.55 on SunOS raises some compiler warnings. You might want to >>avoid them. >> . . . >>charsets.c: In function `translate_character': >>charsets.c:116: warning: passing arg 2 of `iconv' from incompatible pointer >>type >> >> > >What's the declaration of iconv() on your system? glibc-2.2.4 expects >char** at the second argument. > > Fixed in CVS in January, 2002. translate_character use ICONV_CONST now. This one is declared by configure. -- Regards, Andrew V. Samoilov. From kai at cmail.ru Thu Jul 4 11:44:07 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Thu, 4 Jul 2002 14:44:07 +0300 Subject: Extra space in pattern for DOS batch Message-ID: <20020704144407.A208@efp.com.ua> Hi, this patch removes extra space for DOS Batch file(s) pattern. --- syntax/Syntax Tue Jun 25 07:08:08 2002 +++ syntax/Syntax Thu Jul 4 14:39:42 2002 @@ -96,7 +96,7 @@ include changelog.syntax file .\*[Mm]akefile[\\\.a-z]\*$ Makefile include makefile.syntax -file ..\*\\.(bat|cmd) $ DOS\sBatch +file ..\*\\.(bat|cmd)$ DOS\sBatch include dos.syntax file ..\*\\.(po|pot|pox)$ PO\sFile From kai at cmail.ru Thu Jul 4 11:53:18 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Thu, 4 Jul 2002 14:53:18 +0300 Subject: Only binary package in http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ Message-ID: <20020704145318.A219@efp.com.ua> Hi! There is only binary mc-4.5.99a-1.i386.rpm now, but no sources snapshot. -- Regards, Andrew V. Samoilov From proski at gnu.org Fri Jul 5 04:04:30 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 5 Jul 2002 00:04:30 -0400 (EDT) Subject: Extra space in pattern for DOS batch In-Reply-To: <20020704144407.A208@efp.com.ua> Message-ID: > -file ..\*\\.(bat|cmd) $ DOS\sBatch > +file ..\*\\.(bat|cmd)$ DOS\sBatch Applied. -- Regards, Pavel Roskin From proski at gnu.org Fri Jul 5 03:58:23 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 4 Jul 2002 23:58:23 -0400 (EDT) Subject: Only binary package in http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ In-Reply-To: <20020704145318.A219@efp.com.ua> Message-ID: On Thu, 4 Jul 2002, Andrew V. Samoilov wrote: > Hi! > > There is only binary mc-4.5.99a-1.i386.rpm now, > but no sources snapshot. Yes, fixed already. There was a bug in my upload script - it was erasing all files matching mc* except the most recent one. -- Regards, Pavel Roskin From ptsekov at gmx.net Tue Jul 9 15:06:04 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 9 Jul 2002 17:06:04 +0200 (MEST) Subject: mc-4.5.55 is now part of the Cygwin net distribution Message-ID: <20753.1026227164@www17.gmx.net> Hello, there! :) I thought it would be a good idea to drop a note - as of today the the Midnight Commander has been included in the Cygwin net distribution. I'm the one which will actually maintain the Cygwin package for MC. I've used the last officialy released MC version for the Cygwin port. Actually it is hard to call it a port, since it compiles OOB on current (1.3.12) cygwin and I haven't done any Cygwin specific changes to the code - yet :) I've just red the official MC announcement posted back in August 2001 and I noticed that it talks about some kind of troubles using the viewer/editor. I don't really share this experience although the code base is the same. Are you aware of any other problems which MC might have on Cygwin ? I'd like to know of them so I can help improve MC for that platform. Currently the most annoying problem I'm aware of is the subshell support, which if used, causes MC to hang. This is a Cygwin issue and I'm working to fix it. There was also a nasty bug, when using MAD compiled MC - as long as I remember a memory address pointing to malloc()-ed memory is passed to the MAD free incremented by 4. This issue caused a nasty crash when closing the MC editor. I spent some time to identify that this is a MAD problem, but havent actully traced the source of the problem - just disabled MAD :( Maybe you're already aware of that one... Last thing - I suppose that many things have changed after the last official release was made - is it possible to resume any of the most important changes ? Thanks! :) Pave Tsekov -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From proski at gnu.org Tue Jul 9 16:21:09 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 9 Jul 2002 12:21:09 -0400 (EDT) Subject: mc-4.5.55 is now part of the Cygwin net distribution In-Reply-To: <20753.1026227164@www17.gmx.net> Message-ID: Hi, Pavel! > I thought it would be a good idea to drop a note - as of today the the > Midnight Commander has been included in the Cygwin net distribution. Very good news. > I'm the one which will actually maintain the Cygwin package for MC. I've > used the last officialy released MC version for the Cygwin port. > Actually it is hard to call it a port, since it compiles OOB on current > (1.3.12) cygwin and I haven't done any Cygwin specific changes to the > code - yet :) > > I've just red the official MC announcement posted back in August 2001 > and I noticed that it talks about some kind of troubles using the > viewer/editor. I don't really share this experience although the code > base is the same. The problem is that MC was using some internal regex functions from regex.c file included with the distribution. This should be fixed now. You may be lucky if your libc has different names for the functions used in regex.c. > Are you aware of any other problems which MC might have on Cygwin ? I'd > like to know of them so I can help improve MC for that platform. I haven't compiled it on Cygwin for a long time, but I think problems with line endings still need to be worked on. Prompt loading from the subshell doesn't work well on any OS, but it may be more broken on less UNIX-like systems, including Cygwin. VFS is a big mess, and I don't think it works well on Cygwin, if at all. > Currently the most annoying problem I'm aware of is the subshell > support, which if used, causes MC to hang. This is a Cygwin issue and > I'm working to fix it. Please try the current snapshot from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ I fixed a related bug recently. Basically, there is a list of file descriptors to be monitored, and one of them is used to load prompt from the subshell. This descriptor wasn't removed from the list if the subshell died for any reason. It may be easier to fix subshell now if it still doesn't work, because you won't get 100% CPU utilization in get_event(). > There was also a nasty bug, when using MAD compiled MC - as long as I > remember a memory address pointing to malloc()-ed memory is passed to > the MAD free incremented by 4. This issue caused a nasty crash when > closing the MC editor. I spent some time to identify that this is a MAD > problem, but havent actully traced the source of the problem - just > disabled MAD :( Maybe you're already aware of that one... A lot of work has been done on MAD by Andrew V. Samoilov If you still get this error with the the snapshot, please give more details. > Last thing - I suppose that many things have changed after the last > official release was made - is it possible to resume any of the most > important changes ? http://cvs.gnome.org/lxr/source/mc/NEWS?raw=1 -- Regards, Pavel Roskin From avarakin00 at hotmail.com Wed Jul 10 02:50:44 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Tue, 9 Jul 2002 22:50:44 -0400 Subject: mc-4.5.55 is now part of the Cygwin net distribution References: Message-ID: Hi Pavels, I think it will be a very good idea to port the latest snapshot. I built MC from snapshot about 3 months ago and I was having the following problems: 0. regex.c - fixed by me 1. subshell dies after few Ctrl-O, then mc dies. It happens very quickly under rxvt or xterm, but if started from DOS box, it works for quite a while, but then it still eventually dies. I doubt this is a cygwin problem, because the well known unix "screen" works under cygwin without any problems, although it also uses pty's. Maybe it is a good idea to see the sources of screen and find out how the subshell must be done. 2. MC barks on 'pagefile.sys' : ************************************************ File 'pagefile.sys' exists but can not be stat-ed: Permission denied ************************************************ This is actually a general problem, I saw it on unixes as well, but it is very annoying under cygwin. 3. editor and viewer don't work properly on filesystem, mounted in text mode, editor even corrupts files in DOS encoding. The solution is to change mc editor to open all files in binary mode using "w+b" method. Even if to do so, there is a problem with ^M's at the ends of lines, which are invisible and can be easily mixed up with text and screw up the file. This is also common problem with unix if one has to edit files in dos encoding. I was having a lot of trouble because of this since all C++ files in our clearcase are in DOS encoding. I saw some remains of code in MC which are supposed to do some CR-LF translation, I tried to enable it, but mc just crashed. Pavel, any suggestions how this can be fixed properly? 4. The border lines are screwed up while running inside DOS box or rxvt. Not a big deal, but not aesthetic. I would be very happy to take part in cygwin port, I will try to fix the editor. Alex ----- Original Message ----- From: "Pavel Roskin" To: "Pavel Tsekov" Cc: Sent: Tuesday, July 09, 2002 12:21 PM Subject: Re: mc-4.5.55 is now part of the Cygwin net distribution > Hi, Pavel! > > > I thought it would be a good idea to drop a note - as of today the the > > Midnight Commander has been included in the Cygwin net distribution. > > Very good news. > > > I'm the one which will actually maintain the Cygwin package for MC. I've > > used the last officialy released MC version for the Cygwin port. > > Actually it is hard to call it a port, since it compiles OOB on current > > (1.3.12) cygwin and I haven't done any Cygwin specific changes to the > > code - yet :) > > > > I've just red the official MC announcement posted back in August 2001 > > and I noticed that it talks about some kind of troubles using the > > viewer/editor. I don't really share this experience although the code > > base is the same. > > The problem is that MC was using some internal regex functions from > regex.c file included with the distribution. This should be fixed now. > > You may be lucky if your libc has different names for the functions > used in regex.c. > > > Are you aware of any other problems which MC might have on Cygwin ? I'd > > like to know of them so I can help improve MC for that platform. > > I haven't compiled it on Cygwin for a long time, but I think problems with > line endings still need to be worked on. > > Prompt loading from the subshell doesn't work well on any OS, but it may > be more broken on less UNIX-like systems, including Cygwin. > > VFS is a big mess, and I don't think it works well on Cygwin, if at all. > > > Currently the most annoying problem I'm aware of is the subshell > > support, which if used, causes MC to hang. This is a Cygwin issue and > > I'm working to fix it. > > Please try the current snapshot from > http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ > > I fixed a related bug recently. Basically, there is a list of file > descriptors to be monitored, and one of them is used to load prompt from > the subshell. This descriptor wasn't removed from the list if the > subshell died for any reason. > > It may be easier to fix subshell now if it still doesn't work, because you > won't get 100% CPU utilization in get_event(). > > > There was also a nasty bug, when using MAD compiled MC - as long as I > > remember a memory address pointing to malloc()-ed memory is passed to > > the MAD free incremented by 4. This issue caused a nasty crash when > > closing the MC editor. I spent some time to identify that this is a MAD > > problem, but havent actully traced the source of the problem - just > > disabled MAD :( Maybe you're already aware of that one... > > A lot of work has been done on MAD by Andrew V. Samoilov > If you still get this error with the the snapshot, please give more > details. > > > Last thing - I suppose that many things have changed after the last > > official release was made - is it possible to resume any of the most > > important changes ? > > http://cvs.gnome.org/lxr/source/mc/NEWS?raw=1 > > -- > Regards, > Pavel Roskin > > _______________________________________________ > Mc-devel mailing list > Mc-devel at gnome.org > http://mail.gnome.org/mailman/listinfo/mc-devel > From proski at gnu.org Wed Jul 10 06:47:49 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 10 Jul 2002 02:47:49 -0400 (EDT) Subject: mc-4.5.55 is now part of the Cygwin net distribution In-Reply-To: Message-ID: Hi, Alexander! > I built MC from snapshot about 3 months ago and I was having the following > problems: > 0. regex.c - fixed by me Thank you. It's indeed fixed. > 1. subshell dies after few Ctrl-O, then mc dies. It happens very quickly > under rxvt or xterm, but if started from DOS box, it works for quite a > while, but then it still eventually dies. I doubt this is a cygwin > problem, because the well known unix "screen" works under cygwin without > any problems, although it also uses pty's. Maybe it is a good idea to > see the sources of screen and find out how the subshell must be done. Yes, I could reproduce it today. I don't have Windows at home and I don't have time at work, so a few ideas for you. Two ways to debug it: 1) There is some error message. Try ignoring this error in the code and see what happens. Maybe the error should result in disabling the subshell, but it kills mc as well? 2) Add some debug statements that would print the current file and line to stderr, redirect stderr and see where MC hangs. My guess it that it's get_event(). If so, we should not be ignoring exceptions in select(), since they cause the loop. The problem that triggers the exception should be fixed too. > 2. MC barks on 'pagefile.sys' : > ************************************************ > File 'pagefile.sys' exists but can not be stat-ed: Permission denied > ************************************************ > This is actually a general problem, I saw it on unixes as well, but it is > very annoying under cygwin. Yes, MC tries to stat() every file and "barks". Unless you have a clean and simple solution, it's not going to be fixed soon. I think MC could show those ghost-entries using a distinctive color, but avoid any messages. > 3. editor and viewer don't work properly on filesystem, mounted in text > mode, editor even corrupts files in DOS encoding. > The solution is to change mc editor to open all files in binary mode using > "w+b" method. That's probably the right thing. > Even if to do so, there is a problem with ^M's at the ends of lines, which > are invisible and can be easily mixed up with text and screw up the file. > This is also common problem with unix if one has to edit files in dos > encoding. Right, this is not a Cygwin problem. > I was having a lot of trouble because of this since all C++ files in our > clearcase are in DOS encoding. Try using an external editor for now. > I saw some remains of code in MC which are supposed to do some CR-LF > translation, I tried to enable it, but mc just crashed. > Pavel, any suggestions how this can be fixed properly? This code is from Cooledit. I doubt that it ever worked properly. > 4. The border lines are screwed up while running inside DOS box or rxvt. Not > a big deal, but not aesthetic. It's a known problem - using ASCII approximation can only be forced through a command line option. Per-terminal settings are not implemented and not planned to be in the next version. You could look if it's possible to use pseudographics. Maybe terminfo doesn't describe the Cygwin terminal correctly? > I would be very happy to take part in cygwin port, I will try to fix the > editor. Good luck. -- Regards, Pavel Roskin From ptsekov at gmx.net Wed Jul 10 09:43:16 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 10 Jul 2002 11:43:16 +0200 (MEST) Subject: mc-4.5.55 is now part of the Cygwin net distribution References: Message-ID: <1360.1026294196@www63.gmx.net> Hey, Alex :) > I think it will be a very good idea to port the latest snapshot. I've downloaded it and compiled it last night.. Looks good so far. One problem though which i don't see in 4.5.55 - when displaying a directory listing the parent dir (..) MTime is incorrect - Jan 1 1970 > I built MC from snapshot about 3 months ago and I was having the following > problems: > 0. regex.c - fixed by me Are you changes in the current CVS ? Could you give some more details ? There were changes some months ago in the Cygwin regex functions. > 1. subshell dies after few Ctrl-O, then mc dies. It happens very quickly > under rxvt or xterm, but if started from DOS box, it works for quite a > while, but then it still eventually dies. > I doubt this is a cygwin problem, because the well known unix "screen" > works under cygwin without any problems, although it also uses pty's. > Maybe > it is a good idea to see the sources of screen and find out how the > subshell > must be done. This is indeed the problem I'm talking about and it is a Cygwin problem. I'm a bash user, so I don't know if it is the same with tcsh or zsh. Basically the problem is that at one point the subshell is suspended and doesn't receive the SIGCONT signal which mc sends it - then mc hangs waiting for it to awake. I think this is a problem/race in Cygwin signal handling - as soon as I have more free time I'd investigate further. > > 2. MC barks on 'pagefile.sys' : > ************************************************ > File 'pagefile.sys' exists but can not be stat-ed: Permission denied > ************************************************ > This is actually a general problem, I saw it on unixes as well, but it is > very annoying under cygwin. Yes and some other files in the root of your C:\ drive (or where your pagefile is). There are also some other files - hiberfil.sys for example on NT. But you cant open these files even from windows. > 4. The border lines are screwed up while running inside DOS box or rxvt. > Not > a big deal, but not aesthetic. Screwed how ? If you use 'graphical' characters ? You can set your CYGWIN variable to contain codepage:oem - this will fix the problem. > I would be very happy to take part in cygwin port, I will try to fix the > editor. Thanks! :) Pavel Tsekov -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From ptsekov at gmx.net Wed Jul 10 13:51:59 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 10 Jul 2002 15:51:59 +0200 (MEST) Subject: copy_file_file() fails on cygwin when the source is on externel FS (extfs) Message-ID: <23055.1026309119@www29.gmx.net> Please, take a look a the following link: http://www.cygwin.com/ml/cygwin/2002-07/msg00786.html The problem is that the temporary file (/tmp/extfsXXXXXX), representing a file in the external FS, is opened with O_RDONLY and O_APPEND. I was curious what is the purpose of O_LINEAR if we're opening the file for reading. Thanks! Pavel Tsekov -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From zlatko at gmx.at Wed Jul 10 17:27:07 2002 From: zlatko at gmx.at (Thomas Zajic) Date: Wed, 10 Jul 2002 19:27:07 +0200 Subject: Things to do before 4.6.0 In-Reply-To: References: Message-ID: <20020710172707.GE5817@sphere.fdns.net> * Pavel Roskin , 26/06/2002, 05:17 > This is a list of things that I want to be done before the 4.6.0 release. > [...] > 1) Review the outstanding patches in this list and apply them, unless > they seem unstable or introduce new features. Resubmitting of patches > with more detailed comments would help, but is not required. Which reminds me: is there any basic problem with my .netrc patch that I'm probably not aware of (except, maybe, that it isn't exactly a showcase of extreme elegance in C programming :-)? Is this one of the new features that will be held back until 4.6.0 has been released, or one of those waiting in the queue to be reviewed? Or am I really the only one who is using mc *and* actually finds ~/.netrc useful? Just curious ... The initial problems [1] have been cleaned up, to the best of my knowledge. The last discussion [2] concerned the strcpy vs. strncpy (non-)problem. I'll attach the latest version (which is basically the same as the ones before, except that it is now against 2002-07-09-16), which applies and compiles cleanly without warnings (that, and all occurrences of strncpy() have been replaced by strcpy()). RFC: as you might know, I'm using "*netrc*" as an internal dummy user name. While this seems to be a rather unusual user name for a Unix system, I'm not sure whether it is actually an illegal one as well. Would it be safer to use ":netrc:" instead (my chown(1) man page tells me that according to POSIX, a ":" colon is not a valid character in a user name)? Coming to think of it, I'd probably be better off just using ":netrc:" and stop worrying (provided that this doesn't break parsing URLs that contain user name & password ["ftp://user:password at host/dir/"], I'd have to look into that first), but still: what about non-Unix/non-POSIX systems - should I care? Any & all comments appreciated. TIA, Thomas [1] http://mail.gnome.org/archives/mc-devel/2002-April/msg00055.html [2] http://mail.gnome.org/archives/mc-devel/2002-May/msg00006.html -- =-------------------------------------------------------------------------= - Thomas "ZlatkO" Zajic Linux-2.4.18 & Mutt-1.4i - - "It is not easy to cut through a human head with a hacksaw." (M. C.) - =-------------------------------------------------------------------------= -------------- next part -------------- diff -urp mc-4.5.99a/src/boxes.c mc-4.5.99a-netrc/src/boxes.c --- mc-4.5.99a/src/boxes.c Mon Oct 1 08:51:15 2001 +++ mc-4.5.99a-netrc/src/boxes.c Wed Jul 10 17:15:51 2002 @@ -716,9 +716,18 @@ tree_box (char *current_dir) #ifdef USE_VFS #if defined(USE_NETCODE) +#if defined(USE_NETRC) +#define VFSY 15 +#define VFS_WIDGETBASE 8 +#define NETRC_OFFSET 1 +#else #define VFSY 14 +#define VFS_WIDGETBASE 7 +#define NETRC_OFFSET 0 +#endif #else #define VFSY 8 +#define VFS_WIDGETBASE 0 #endif #define VFSX 56 @@ -741,18 +750,16 @@ static char *ret_ftp_proxy; static int ret_use_netrc; #endif -#if 0 -/* Not used currently */ -{ quick_checkbox, 4, VFSX, 10, VFSY, "Use ~/.netrc", - 'U', 0, 0, &ret_use_netrc, 0, "" }, -#endif - static QuickWidget confvfs_widgets [] = { { quick_button, 30, VFSX, VFSY - 3, VFSY, N_("&Cancel"), 0, B_CANCEL, 0, 0, "button-cancel" }, { quick_button, 12, VFSX, VFSY - 3, VFSY, N_("&Ok"), 0, B_ENTER, 0, 0, "button-ok" }, #if defined(USE_NETCODE) +#if defined(USE_NETRC) +{ quick_checkbox, 4, VFSX, 10, VFSY, N_("&Use ~/.netrc"), 0, 0, + &ret_use_netrc, 0, "check-use-netrc" }, +#endif { quick_input, 4, VFSX, 9, VFSY, "", 48, 0, 0, &ret_ftp_proxy, "input-ftp-proxy" }, { quick_checkbox, 4, VFSX, 8, VFSY, N_("&Always use ftp proxy"), 0, 0, @@ -780,12 +787,6 @@ static QuickWidget confvfs_widgets [] = static QuickDialog confvfs_dlg = { VFSX, VFSY, -1, -1, N_(" Virtual File System Setting "), "[Virtual FS]", "quick_vfs", confvfs_widgets, 0 }; -#if defined(USE_NETCODE) -#define VFS_WIDGETBASE 7 -#else -#define VFS_WIDGETBASE 0 -#endif - void configure_vfs (void) { @@ -799,9 +800,9 @@ configure_vfs (void) #if defined(USE_NETCODE) ret_use_netrc = use_netrc; g_snprintf(buffer3, sizeof (buffer3), "%i", ftpfs_directory_timeout); - confvfs_widgets[5].text = buffer3; - confvfs_widgets[7].text = ftpfs_anonymous_passwd; - confvfs_widgets[2].text = ftpfs_proxy_host; + confvfs_widgets[5 + NETRC_OFFSET].text = buffer3; + confvfs_widgets[7 + NETRC_OFFSET].text = ftpfs_anonymous_passwd; + confvfs_widgets[2 + NETRC_OFFSET].text = ftpfs_proxy_host; #endif if (quick_dialog (&confvfs_dlg) != B_CANCEL) { diff -urp mc-4.5.99a/vfs/ftpfs.c mc-4.5.99a-netrc/vfs/ftpfs.c --- mc-4.5.99a/vfs/ftpfs.c Wed Jul 3 21:55:39 2002 +++ mc-4.5.99a-netrc/vfs/ftpfs.c Wed Jul 10 17:15:51 2002 @@ -162,6 +162,9 @@ static int command (vfs *me, vfs_s_super __attribute__ ((format (printf, 4, 5))); static int ftpfs_open_socket (vfs *me, vfs_s_super *super); static int login_server (vfs *me, vfs_s_super *super, const char *netrcpass); +#ifdef USE_NETRC +int lookup_netrc (char *host, char **login, char **pass); +#endif static char * translate_path (vfs *me, vfs_s_super *super, const char *remote_path) @@ -814,6 +817,12 @@ open_archive (vfs *me, vfs_s_super *supe super->root = vfs_s_new_inode (me, super, vfs_s_default_stat(me, S_IFDIR | 0755)); if (password) SUP.password = password; +#ifdef USE_NETRC + /* try to get user and/or password from ~/.netrc */ + else if (use_netrc) + lookup_netrc(SUP.host, &SUP.user, &SUP.password); +#endif + return open_archive_int (me, super); } @@ -821,6 +830,9 @@ static int archive_same(vfs *me, vfs_s_super *super, char *archive_name, char *op, void *cookie) { char *host, *user; +#ifdef USE_NETRC + char *pass = NULL; +#endif int port; op = vfs_split_url (strchr(op, ':')+1, &host, &user, &port, 0, 21, URL_DEFAULTANON); @@ -828,6 +840,12 @@ archive_same(vfs *me, vfs_s_super *super if (op) g_free (op); +#ifdef USE_NETRC + /* replace the dummy user with the one from ~/.netrc */ + if (use_netrc && !strcmp(user, "*netrc*")) + lookup_netrc(SUP.host, &user, &pass); +#endif + port = ((strcmp (host, SUP.host) == 0) && (strcmp (user, SUP.user) == 0) && (port == SUP.port)); @@ -1936,13 +1954,16 @@ int lookup_netrc (char *host, char **log } *rup_cache = NULL, *rupp; for (rupp = rup_cache; rupp != NULL; rupp = rupp->next) - if (!strcmp (host, rupp->host)) { - if (rupp->login != NULL) - *login = g_strdup (rupp->login); - if (rupp->pass != NULL) - *pass = g_strdup (rupp->pass); - return 0; - } + /* return from cache only if host AND user match! */ + if ((!strcmp (host, rupp->host)) && + (rupp->login != NULL) && + (*login != NULL) && + (!strcmp(rupp->login, *login))) { + *login = g_strdup (rupp->login); + if (rupp->pass != NULL) + *pass = g_strdup (rupp->pass); + return 0; + } netrcname = concat_dir_and_file (home_dir, ".netrc"); netrcp = netrc = load_file (netrcname); if (netrc == NULL) { @@ -1970,7 +1991,8 @@ int lookup_netrc (char *host, char **log switch (keyword) { case 3: if (netrc_next ()) { - if (*login == NULL) + /* replace the dummy user with the one from ~/.netrc */ + if ((*login == NULL) || !strcmp(*login, "*netrc*")) *login = g_strdup (buffer); else if (strcmp (*login, buffer)) keyword = 20; @@ -2015,8 +2037,12 @@ int lookup_netrc (char *host, char **log rupp->host = g_strdup (host); rupp->login = rupp->pass = 0; - if (*login != NULL) + if (*login != NULL) { + if (!strcmp(*login, "*netrc*")) + /* no match in ~/.netrc, try anonymous */ + *login = g_strdup("anonymous"); rupp->login = g_strdup (*login); + } if (*pass != NULL) rupp->pass = g_strdup (*pass); rupp->next = rup_cache; Only in mc-4.5.99a-netrc/vfs: ftpfs.c~ diff -urp mc-4.5.99a/vfs/utilvfs.c mc-4.5.99a-netrc/vfs/utilvfs.c --- mc-4.5.99a/vfs/utilvfs.c Fri Aug 3 12:12:18 2001 +++ mc-4.5.99a-netrc/vfs/utilvfs.c Wed Jul 10 17:15:51 2002 @@ -69,6 +69,10 @@ char *vfs_split_url (const char *path, c char *pcopy = g_strdup (path); char *pend = pcopy + strlen (pcopy); int default_is_anon = flags & URL_DEFAULTANON; +#ifdef USE_NETRC + /* get user from ~/.netrc if we're supposed to */ + int default_is_netrc = use_netrc; +#endif if (pass) *pass = NULL; @@ -103,8 +107,13 @@ char *vfs_split_url (const char *path, c } if (*pcopy != 0) *user = g_strdup (pcopy); - else + else { default_is_anon = 0; +#ifdef USE_NETRC + /* don't lookup ~/.netrc, use login name instead */ + default_is_netrc = 0; +#endif + } if (pend == at+1) rest = at; @@ -112,6 +121,12 @@ char *vfs_split_url (const char *path, c rest = at + 1; } else rest = pcopy; + +#ifdef USE_NETRC + /* dummy user to be replaced in lookup_netrc() in ftpfs.c */ + if (!*user && (default_is_netrc == 1)) + *user = g_strdup ("*netrc*"); +#endif if (!*user){ if (default_is_anon) diff -urp mc-4.5.99a/vfs/utilvfs.h mc-4.5.99a-netrc/vfs/utilvfs.h --- mc-4.5.99a/vfs/utilvfs.h Mon Jun 25 23:34:46 2001 +++ mc-4.5.99a-netrc/vfs/utilvfs.h Wed Jul 10 17:15:51 2002 @@ -3,3 +3,7 @@ #include "../src/tty.h" /* enable/disable interrupt key */ #include "../src/background.h" #include "../src/main.h" + +#ifdef USE_NETRC +extern int use_netrc; +#endif From proski at gnu.org Wed Jul 10 18:03:04 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 10 Jul 2002 14:03:04 -0400 (EDT) Subject: copy_file_file() fails on cygwin when the source is on externel FS (extfs) In-Reply-To: <23055.1026309119@www29.gmx.net> Message-ID: Hi, Pavel! > Please, take a look a the following link: > http://www.cygwin.com/ml/cygwin/2002-07/msg00786.html Looks like a bug in Cygwin that need to be fixed. > The problem is that the temporary file (/tmp/extfsXXXXXX), representing a > file in the external FS, is opened with O_RDONLY and O_APPEND. > > I was curious what is the purpose of O_LINEAR if we're opening the file for > reading. There is an explanation in vfs.h. O_LINEAR is used as a kludge to inform VFS that the file will be read without seeks. However, VFS should not pass this kludge to the real open(). This bug has been fixed. The new snapshot is waiting for you. Thanks! You can simply apply this patch (in vfs directory): ========================== --- ChangeLog +++ ChangeLog @@ -1 +1,9 @@ +2002-07-10 Pavel Roskin + + * direntry.c (vfs_s_open): Don't pass O_LINEAR to open() - + this flag is for VFS only, and causes side effects in Cygwin. + * extfs.c (extfs_open): Likewise. + * sfs.c (sfs_open): Likewise. + Reported by Pavel Tsekov + 2002-07-03 Pavel Roskin --- direntry.c +++ direntry.c @@ -800,7 +800,7 @@ vfs_s_open (vfs *me, char *file, int fla } if (fh->ino->localname){ - fh->handle = open (fh->ino->localname, flags, mode); + fh->handle = open (fh->ino->localname, NO_LINEAR(flags), mode); if (fh->handle == -1){ g_free(fh); ERRNOR (errno, NULL); --- extfs.c +++ extfs.c @@ -657,7 +657,8 @@ static void *extfs_open (vfs *me, char * g_free (cmd); } - local_handle = open (entry->inode->local_filename, flags, mode); + local_handle = open (entry->inode->local_filename, NO_LINEAR(flags), + mode); if (local_handle == -1) ERRNOR (EIO, NULL); extfs_info = g_new (struct pseudofile, 1); --- sfs.c +++ sfs.c @@ -157,7 +157,7 @@ sfs_open (vfs *me, char *path, int flags int fd; path = redirect (me, path); - fd = open (path, flags, mode); + fd = open (path, NO_LINEAR(flags), mode); if (fd == -1) return 0; ========================== -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 10 22:00:44 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 10 Jul 2002 18:00:44 -0400 (EDT) Subject: Things to do before 4.6.0 In-Reply-To: <20020710172707.GE5817@sphere.fdns.net> Message-ID: Hi, Thomas! > Which reminds me: is there any basic problem with my .netrc patch that I'm > probably not aware of (except, maybe, that it isn't exactly a showcase of > extreme elegance in C programming :-)? Is this one of the new features that > will be held back until 4.6.0 has been released, or one of those waiting in > the queue to be reviewed? Or am I really the only one who is using mc *and* > actually finds ~/.netrc useful? Just curious ... I've applied your patch with some changes. Now .netrc support is always compliled in for simplicity. It is enabled by default and can be disabled at run time. Having a compile time option to save just one function is not worth it. Variable use_netrc is now declared in one file instead of three, as it was after applying your patch. > Coming to think of it, I'd probably be better off just using ":netrc:" and > stop worrying (provided that this doesn't break parsing URLs that contain > user name & password ["ftp://user:password at host/dir/"], I'd have to look > into that first), but still: what about non-Unix/non-POSIX systems - should > I care? I think "*netrc*" is fine and safer than ":netrc:" exactly because of the parsing. -- Regards, Pavel Roskin From proski at gnu.org Thu Jul 11 05:49:05 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 11 Jul 2002 01:49:05 -0400 (EDT) Subject: .netrc patch breaks fish, possibly mcfs and smbfs In-Reply-To: <20020509024433.M1301@sphere.fdns.net> Message-ID: Hi, Thomas! I've just found a regression in the current version of MC. Fish doesn't work anymore unless the user is specified explicitly. If I don't specify the user, mc tries to login as user "*netrc*" over ssh. For example, if you can set up you system so that "ssh localhost" doesn't ask your password, and you enter "cd /#sh:localhost" on the command line, you get the following message in the status bar: fish: Waiting for initial line...*netrc*@localhost's password: Indeed, vfs_split_url() is called not only by ftpfs, but also by fish, mcfs and smbfs. But only ftpfs knows how to handle "*netrc*". Thomas, do you have any ideas how to fix it? I'll be busy the rest of this week, but I'll apply your fix if you post it. To others: this example demonstrates why I don't want to apply non-trivial patches introducing new features at this stage. The patch was published, and nobody said that it's broken. I spent a lot of time today testing the patch before committing it. I read every line of the patch. Yet I missed the bug and only found it because it introduced a major breakage in the code I use often (fish). If only smbfs was affected, perhaps this bug would not be found before the next release. And now consider the fact that the .netrc patch was fixing the functionality that was already in the code. Any entirely new code would be even riskier to apply. I'm not against new features, but the MC code is very easy to break, and very few people are fixing bugs or preventing them. Broken .netrc was sitting in the code for years. I don't want any new bugs that would remain unfixed for so long. -- Regards, Pavel Roskin From zlatko at gmx.at Thu Jul 11 14:27:53 2002 From: zlatko at gmx.at (Thomas Zajic) Date: Thu, 11 Jul 2002 16:27:53 +0200 Subject: .netrc patch breaks fish, possibly mcfs and smbfs In-Reply-To: References: <20020509024433.M1301@sphere.fdns.net> Message-ID: <20020711142753.GI5817@sphere.fdns.net> * Pavel Roskin , 11/07/2002, 01:49 > I've just found a regression in the current version of MC. Fish doesn't > work anymore unless the user is specified explicitly. If I don't specify > the user, mc tries to login as user "*netrc*" over ssh. > [...] > Indeed, vfs_split_url() is called not only by ftpfs, but also by fish, > mcfs and smbfs. But only ftpfs knows how to handle "*netrc*". Argh! That just *had to* happen, of course. 8-( > Thomas, do you have any ideas how to fix it? I'll be busy the rest of > this week, but I'll apply your fix if you post it. Off-hand, without looking at the code, I can think of two similar quick- and-dirty fixes, with a similar degree of ugliness: 1. Introduce a global variable that is set before calling, and then read by vfs_split_url(), telling it whether or not to use the netrc code. ftpfs would set it to TRUE, all others to FALSE. Advantage: changes to the actual code could be reduced to only those source files that I already modified with my patch anyway, simply by initializing the global to 0/FALSE, and then doing something like called_from_ftpfs = 1; vfs_split_url(); called_from_ftpfs = 0; in the ftpfs related code. 2. Add a new parameter to be passed to vfs_split_url(), with the same meaning as above. Advantage: when #defined as a macro (which would automagically add the correct values for ftpfs, fish, mcfs and smbfs) in the respective headers, the change becomes more or less transparent to the existing code. Moreover, this would catch accidental breakages in the future, caused by, for example, calling vfs_split_url() from some new or other place(s) (ie. VFS subsystems) than now, without properly setting the global first. In the vfs_split_url() code itself, the new global/parameter would more or less do the same thing at runtime that the "#ifdef USE_NETRC" parts do (or rather, did - as I understand the #ifdefs are completely gone now) at compile time in my original patch, and the "if (use_netrc == 1)" parts would have to be changed to "if (use_netrc && called_from_ftpfs)". Personally, I'd rather go for solution 2. (and changing the actual calls to vfs_split_url() instead of using a #define, coming to think of it), because it feels slightly cleaner and safer (with respect to possible future changes & additions) than 1., and there are already two parameters to vfs_split_url() that are ftpfs specific anyway. What do you think? Bye, Thomas -- =-------------------------------------------------------------------------= - Thomas "ZlatkO" Zajic Linux-2.4.18 & Mutt-1.4i - - "It is not easy to cut through a human head with a hacksaw." (M. C.) - =-------------------------------------------------------------------------= From rebel at atrey.karlin.mff.cuni.cz Thu Jul 11 16:46:33 2002 From: rebel at atrey.karlin.mff.cuni.cz (Michal Svec) Date: Thu, 11 Jul 2002 18:46:33 +0200 (CEST) Subject: Differentiate Open Message-ID: Hi! In the current mc.ext you could often find something like this: Open=if [ "$DISPLAY" = "" ]; then dvisvga %f; else (xdvi %f &); fi It's long and hungus. Thus I propose to split Open into two parts: Open=dvisvga %f XOpen=xdvi %f Advantages: - shorter and cleaner notation - backward compatible - faster execution - patch is small Regards Michal Index: src/ChangeLog =================================================================== RCS file: /cvs/gnome/mc/src/ChangeLog,v retrieving revision 1.751 diff -u -w -r1.751 ChangeLog --- src/ChangeLog 10 Jul 2002 23:27:36 -0000 1.751 +++ src/ChangeLog 11 Jul 2002 07:59:02 -0000 @@ -1,3 +1,8 @@ +2002-04-13 Michal Svec + + * screen.c: differentiate Open if X are running (XOpen) + * ext.c: likewise + 2002-07-10 Pavel Roskin * utilunix.c: Cast argument for GUINT_TO_POINTER to int to fix Index: src/ext.c =================================================================== RCS file: /cvs/gnome/mc/src/ext.c,v retrieving revision 1.37 diff -u -w -r1.37 ext.c --- src/ext.c 21 Feb 2002 14:37:51 -0000 1.37 +++ src/ext.c 11 Jul 2002 07:59:02 -0000 @@ -604,6 +604,7 @@ } if (action == NULL) { if (strcmp (p, "Open") && + strcmp (p, "XOpen") && strcmp (p, "View") && strcmp (p, "Edit") && strcmp (p, "Drop") && Index: src/screen.c =================================================================== RCS file: /cvs/gnome/mc/src/screen.c,v retrieving revision 1.110 diff -u -w -r1.110 screen.c --- src/screen.c 27 Jun 2002 21:25:03 -0000 1.110 +++ src/screen.c 11 Jul 2002 07:59:03 -0000 @@ -1968,7 +1968,7 @@ do_enter_on_file_entry (file_entry *fe) { char *full_name; - char *p; + char *p, *d; /* Directory or link to directory - change directory */ if (S_ISDIR (fe->buf.st_mode) || link_isdir (fe)) { @@ -1977,7 +1977,15 @@ } /* Try associated command */ + d = getenv("DISPLAY"); + if (d && *d) { + p = regex_command (fe->fname, "XOpen", NULL, 0); + if (!p || strcmp (p, "Success")) p = regex_command (fe->fname, "Open", NULL, 0); + } + else + p = regex_command (fe->fname, "Open", NULL, 0); + if (p && (strcmp (p, "Success") == 0)) return 1; From proski at gnu.org Thu Jul 11 20:08:36 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 11 Jul 2002 16:08:36 -0400 (EDT) Subject: Differentiate Open In-Reply-To: Message-ID: Hi, Michal! > In the current mc.ext you could often find something like this: > Open=if [ "$DISPLAY" = "" ]; then dvisvga %f; else (xdvi %f &); fi > > It's long and hungus. It also doesn't work on remote VFS (such as fish, ftpfs) under X. Also xdvi will exit when MC terminates. > Thus I propose to split Open into two parts: > Open=dvisvga %f > XOpen=xdvi %f > > Advantages: > - shorter and cleaner notation > - backward compatible > - faster execution > - patch is small - mc will be able (hopefully) to set up a separate process group in the child and do whatever else is needed to prevent X programs from exiting when mc exits. Very good idea. Thank you. I think XView and XEdit would be useful too. I'm a bit hesitant about applying it now, but if it fixes (well, works around) the problem with the second %f not being expanded by VFS and doesn't introduce any new bugs, it will be applied. -- Regards, Pavel Roskin From proski at gnu.org Thu Jul 11 21:40:02 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 11 Jul 2002 17:40:02 -0400 (EDT) Subject: .netrc patch breaks fish, possibly mcfs and smbfs In-Reply-To: <20020711142753.GI5817@sphere.fdns.net> Message-ID: Hi, Thomas! > 2. Add a new parameter to be passed to vfs_split_url(), with the same > meaning as above. Such parameter already exists. It's called "flags". URL_DEFAULTANON is only set by ftpfs. Either the meaning of URL_DEFAULTANON should be changed, or it should be redefined and possibly renamed. A lot of problems with the mc code exist because new code was added instead of making the existing code work. The simplest fix would be then (plus the necessary comment changes): ============================= --- utilvfs.c +++ utilvfs.c @@ -70,7 +70,7 @@ char *pend = pcopy + strlen (pcopy); int default_is_anon = flags & URL_DEFAULTANON; /* get user from ~/.netrc if we're supposed to */ - int default_is_netrc = use_netrc; + int default_is_netrc = use_netrc & default_is_anon; if (pass) *pass = NULL; ============================= I think that vfs_split_url() needs simplification, and should not deal with netrc, but instead should return NULL as username if the caller promises to handle it. Alternatively, .netrc should be looked up in vfs_split_url(). This would have a positive side effect, since most users are likely to use the same username for different services, including ssh. .netrc is not just for ftp. It is also used e.g. by fetchmail. -- Regards, Pavel Roskin From proski at gnu.org Thu Jul 11 23:57:45 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 11 Jul 2002 19:57:45 -0400 (EDT) Subject: .netrc patch breaks fish, possibly mcfs and smbfs In-Reply-To: Message-ID: Hi, Thomas! > I think that vfs_split_url() needs simplification, and should not deal > with netrc, but instead should return NULL as username if the caller > promises to handle it. I've implemented this approach beacuse it's simple and it restores the old behavior of handling all netrc stuff in ftpfs. Unfortunately, I discovered during the testing that the proxy code is completely broken. SUP.proxy is set to 0 and is never assigned any other value. SUP.use_proxy is only used to disable passive connections. It seems that the proxy code was broken as early as in 1999. And you were wondering if somebody uses netrc. It's pretty typical for MC - you fix a small bug, test it and find another bug during testing and so on. That's why we should write good code from the beginning. Anyway, netrc support works well and all other breakage seems unrelated to your patch. -- Regards, Pavel Roskin From zlatko at gmx.at Fri Jul 12 08:14:53 2002 From: zlatko at gmx.at (Thomas Zajic) Date: Fri, 12 Jul 2002 10:14:53 +0200 Subject: .netrc patch breaks fish, possibly mcfs and smbfs In-Reply-To: References: Message-ID: <20020712081453.GN5817@sphere.fdns.net> * Pavel Roskin , 11/07/2002, 19:57 > > I think that vfs_split_url() needs simplification, and should not deal > > with netrc, but instead should return NULL as username if the caller > > promises to handle it. > > I've implemented this approach beacuse it's simple and it restores the > old behavior of handling all netrc stuff in ftpfs. > [...] > Anyway, netrc support works well and all other breakage seems unrelated > to your patch. Wow ... and you said you'd be too busy until the end of the week - I only downloaded the latest tarball right now. ;-) Thanks, Pavel! Thomas -- =-------------------------------------------------------------------------= - Thomas "ZlatkO" Zajic Linux-2.4.18 & Mutt-1.4i - - "It is not easy to cut through a human head with a hacksaw." (M. C.) - =-------------------------------------------------------------------------= From kai at cmail.ru Fri Jul 12 10:11:16 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Fri, 12 Jul 2002 13:11:16 +0300 Subject: .netrc patch breaks fish, possibly mcfs and smbfs References: Message-ID: <3D2EAB44.5020808@cmail.ru> Pavel Roskin wrote: > Hi, Thomas! > > >>I think that vfs_split_url() needs simplification, and should not deal >>with netrc, but instead should return NULL as username if the caller >>promises to handle it. > > > I've implemented this approach beacuse it's simple and it restores the > old behavior of handling all netrc stuff in ftpfs. > > Unfortunately, I discovered during the testing that the proxy code is > completely broken. SUP.proxy is set to 0 and is never assigned any other > value. SUP.use_proxy is only used to disable passive connections. > > It seems that the proxy code was broken as early as in 1999. And you were > wondering if somebody uses netrc. > > It's pretty typical for MC - you fix a small bug, test it and find another > bug during testing and so on. That's why we should write good code from > the beginning. > > Anyway, netrc support works well and all other breakage seems unrelated to > your patch. > ! static void ! ftp_split_url(char *path, char **host, char **user, int *port, char **pass) ! { ! char *p; . . . ! char *tmp_pass; ! ! /* Caller is not interested in password, but the functions below want ! * a valid pointer */ ! if (!pass) { ! pass = &tmp_pass; ! } . . . Well, vfs_split_url() handles case when pass is NULL, so lines above are unnneded and comment is incorrect. ! ! p = vfs_split_url (path, host, user, port, pass, FTP_COMMAND_PORT, ! URL_ALLOW_ANON); ! ! if (!*user) { ! if (use_netrc) ! lookup_netrc (*host, user, pass); ! else ! *user = g_strdup ("anonymous"); ! } ! ! if (p) ! g_free (p); . . . ! if (pass == &tmp_pass && *pass) ! g_free (*pass); . . . And these 2 lines too. ! } -- Regards, Andrew V. Samoilov. From proski at gnu.org Fri Jul 12 16:55:10 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 12 Jul 2002 12:55:10 -0400 (EDT) Subject: .netrc patch breaks fish, possibly mcfs and smbfs In-Reply-To: <3D2EAB44.5020808@cmail.ru> Message-ID: Hello! > > It seems that the proxy code was broken as early as in 1999. And you were > > wondering if somebody uses netrc. Fixed already. That was really easy to fix. > Well, vfs_split_url() handles case when pass is NULL, so lines above are > unnneded and comment is incorrect. The comment is only partly incorrect. lookup_netrc() cannot handle this. But I'll fix it. -- Regards, Pavel Roskin From proski at gnu.org Sat Jul 13 00:31:00 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 12 Jul 2002 20:31:00 -0400 (EDT) Subject: .netrc support rewritten Message-ID: Hello! I have reimplemented lookup_netrc() and related functions. The scanning in .netrc has been simplified - double loop has been eliminated, which means that lookup_netrc() finds "default" or "machine" for the given hostname only once. The consequence is that .netrc cannot have passwords for more than one user for the same host. I find this limitation reasonable. .netrc can be used to find username for the given host, and having more than one record for the same host would cause undefined behavior. All the logic for looking up password in .netrc for known user has been moved to ftp_split_url(), where it's easier to implement. I tried to make the new code more readable. The old code was too terse, and I'm surprized that Thomas could understand it at all to make his changes. Unfortunately, all the code by Thomas has been removed. There is no special processing for *netrc* anymore. But I hope that the new code is fairly stable and works as it should. The proxy code has been fixed as well. I don't have time to install FTP proxies, but it would be great if somebody tests this code. -- Regards, Pavel Roskin From proski at gnu.org Sat Jul 13 01:13:14 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 12 Jul 2002 21:13:14 -0400 (EDT) Subject: fish upload worked around, need better fix Message-ID: Hello! I have finally found what's going on with upload over fish, which doesn't work reliably with large files (100k and more). The problem is that "dd" (GNU fileutils-4.1) doesn't reread a block if read() returns less bytes than requested. Unfortunately, this happens when dd gets data from ssh (OpenSSH 3.4, linux 2.4.19-rc1, glibc 2.2.4). I believe that at ~100k dd just gets all the data that ssh has available, and interprets the end of data as a "partial block". The solution would be to use blocks 1 byte long - read() is guaranteed to return at least one byte it it's successful. But this approach would use too many resources on the remote machine, since dd actually would call read() and write() for every byte. Using a bigger obs (output block size) helps, but not much, since we still have one read() per byte. I don't know of any widespread and portable alternative to dd that would read a certain number of bytes and then quit (unlike e.g. gzip, that will search for the next file), that would reread partial blocks (unlike dd), and that would not require non-trivial software to decode it's output (od would need sed or awk capable of writing binary zeroes). Maybe I'm missing a very simple solution. The largest block that works for me is 256 bytes long. That's the patch I'm applying now, and it fixes fish upload for me, but better ideas are welcome. There is no guarantee that dd won't get partial reads with 256 bytes blocks on other operating systems or with outher versions of libc. =================================== --- ChangeLog +++ ChangeLog @@ -2,2 +2,5 @@ + * fish.c (file_store): Reduce input block size to 256 bytes, + otherwise dd gets partial blocks. + * ftpfs.c (login_server) [HSC_PROXY]: Fix crash. --- fish.c +++ fish.c @@ -486,22 +486,22 @@ file_store(vfs *me, vfs_s_fh *fh, char * print_vfs_message(_("fish: store %s: sending command..."), name ); /* * FIXME: Limit size to unsigned long for now. - * Files longer than 4096 * ULONG_MAX are not supported. + * Files longer than 256 * ULONG_MAX are not supported. */ if (command (me, super, WAIT_REPLY, "#STOR %lu /%s\n" "> \"/%s\"\n" "echo '### 001'\n" "(\n" - "dd bs=4096 count=%lu\n" + "dd ibs=256 obs=4096 count=%lu\n" "dd bs=%lu count=1\n" ") 2>/dev/null | (\n" "cat > \"/%s\"\n" "cat > /dev/null\n" "); echo '### 200'\n", (unsigned long) s.st_size, name, name, - (unsigned long) (s.st_size >> 12), - ((unsigned long) s.st_size) & (4096 - 1), name) + (unsigned long) (s.st_size >> 8), + ((unsigned long) s.st_size) & (256 - 1), name) != PRELIM) ERRNOR(E_REMOTE, -1); =================================== -- Regards, Pavel Roskin From proski at gnu.org Sun Jul 14 23:08:20 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 14 Jul 2002 19:08:20 -0400 (EDT) Subject: Towards 4.6.0 - progress report Message-ID: Hello! We are a few steps closer to the next release. Checking for ncurses has been fixed, /usr and /usr/local are no longer hardcoded, curses.h can be accepted as an ncurses header. Syntax highlighting with ncurses has been implemented. This feature was demanded many times. Compresses tarballs with padding at the end are now properly recognized. Exit from subshell in viewer and editor has been fixed, as well as the case when the subshell dies. MC exits - that's not the best solution, but at least it's better than a loop using select() an utilizing 100% of CPU time. The problem with copying big files to fish has been worked around by using 256 byte blocks in dd instead of 4k blocks. Better fix would be nice, but it's good enough for 4.6.0. Remaining issues: 1) When making local copies from remote VFS, preserve the original extension to satisfy some programs used in extfs (old versions of RPM). 2) Handle errors on FiSH. Reading unreadable files causes a hang. 3) Don't show non-printable characters in the filenames. It messes the screen and it's inconsistent with user settings for output. 4) Introduce a new variable for mc.ext that would expand to the filename with the full path. Mozilla and OpenOffice.org need it, since they don't default to the current directory. %d/%p doesn't create local copies, so it's not a solution. 5) Super-long filenames in zip files (>8k) cause buffer overflow in VFS code. Any help with the above issues will be appreciated. -- Regards, Pavel Roskin From dmartina at excite.com Mon Jul 15 11:29:48 2002 From: dmartina at excite.com (David Martin) Date: Mon, 15 Jul 2002 07:29:48 -0400 (EDT) Subject: "Pause after run" && Scripts Message-ID: <20020715112948.18481B6D2@xmxpita.excite.com> It seems to be something about subshell changes. I've noticed this from last snapshot (about one week old). I have some scripts to manage my web, which I use to launch from mc, see their output and push a key to get the panels back. Now, if I just press on them they execute and go back to the panels. Hint: If I change the first line from: #!/bin/sh to ##!/bin/sh (yes, you can remove the line) ...things then go back to the old behavior. *8-) David ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmartina at excite.com Mon Jul 15 11:33:54 2002 From: dmartina at excite.com (David Martin) Date: Mon, 15 Jul 2002 07:33:54 -0400 (EDT) Subject: New translatable message ? Message-ID: <20020715113354.D9B0DB6D2@xmxpita.excite.com> When updating po files I see a "fuzzy" entry about vfs/cpio: 361 The message seems (to me) to be the same as in vfs/cpio:311. (corrupt x corrupted). Is there a real meaningful difference or could the be made the same? If so, could someone fix the new one? *8-) David ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ptsekov at gmx.net Mon Jul 15 12:01:56 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 15 Jul 2002 14:01:56 +0200 (MEST) Subject: 2002-07-10 changes in subshell.c Message-ID: <24772.1026734516@www49.gmx.net> Hello, there! :) 2002-07-10 Pavel Roskin * subshell.c: ioctl() doesn't set errno - don't use perror() to report failures. Use fprintf() instead, ignore errors from TIOCSWINSZ. I've noticed this changelog entry and I'm curious if the change is actually good. In fact ioctl() should set errno approapriately. However there is a bug in Cygwin's implementation of ioctl() + TIOCSWINSZ - please read more about it here: http://www.cygwin.com/ml/cygwin/2002-06/msg00820.html It would be helpful if you read the whole thread on that topic. So, I want to say, that if the decision you've made is based on Cygwin's implementation of that specific ioctl function - it is not right. Thanks! Pavel Tsekov -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From proski at gnu.org Mon Jul 15 15:46:21 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 15 Jul 2002 11:46:21 -0400 (EDT) Subject: "Pause after run" && Scripts In-Reply-To: <20020715112948.18481B6D2@xmxpita.excite.com> Message-ID: Hi, David! > It seems to be something about subshell changes. I've noticed this from > last snapshot (about one week old). I confirm the bug. Even setting "Pause after run..." to "Always" in Options->Configuration doesn't help. This option is ignored with binaries and executable scripts. I guess this is related to my fixes that make it possible to exit from the subshell invoked from the editor or viewer. Unfortunately, the subshell code is very fragile and mostly undocumented. I appreciate that you found and reported this bug. I'll have a closer look. -- Regards, Pavel Roskin From proski at gnu.org Mon Jul 15 16:21:10 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 15 Jul 2002 12:21:10 -0400 (EDT) Subject: New translatable message ? In-Reply-To: <20020715113354.D9B0DB6D2@xmxpita.excite.com> Message-ID: Hi, David! > When updating po files I see a "fuzzy" entry about > > vfs/cpio: 361 > > The message seems (to me) to be the same as in vfs/cpio:311. (corrupt x > corrupted). Is there a real meaningful difference or could the be made > the same? If so, could someone fix the new one? Merriam-Webster OnLine defines "corrupt" (adjective) as: 1 a : morally degenerate and perverted : DEPRAVED b : characterized by improper conduct (as bribery or the selling of favors) 2 : PUTRID, TAINTED 3 : adulterated or debased by change from an original or correct condition synonym see VICIOUS Hardly any of those meanings is suitable for an ASCII string in the beginning of a cpio archive. I have no idea why hexadecimal numbers can be "corrupt", while octal numbers in the old style header are in the worst case "corrupted" :-) I'm reverting this change. Thank you for your help! -- Regards, Pavel Roskin From proski at gnu.org Mon Jul 15 19:19:42 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 15 Jul 2002 15:19:42 -0400 (EDT) Subject: 2002-07-10 changes in subshell.c In-Reply-To: <24772.1026734516@www49.gmx.net> Message-ID: Hi, Pavel! > * subshell.c: ioctl() doesn't set errno - don't use perror() to > report failures. Use fprintf() instead, ignore errors from > TIOCSWINSZ. > > I've noticed this changelog entry and I'm curious if the change is > actually good. In fact ioctl() should set errno approapriately. However > there is a bug in Cygwin's implementation of ioctl() + TIOCSWINSZ - > please read more about it here: > http://www.cygwin.com/ml/cygwin/2002-06/msg00820.html I understand there are two separate problems. One problem is that TIOCSWINSZ doesn't work on pty as it should. Another problem is that it's possible for ioctl() to return a non-zero value without errno becoming non-zero. The discussion seems to cover the pty problem only, and doesn't really discuss setting of errno. Under Linux, ioctl() returns -1 for any failure, and errno is set to the negated result of the return code from the kernel (the kernel returns negative values, and errno is positive). In case of success, the original errno is preserved. My comment in Changelog is wrong in general, but it's true for Cygwin, or so it seems. Anyway, it's just not worth the trouble to bother users with such petty failures, especially since they are hard to display (if we are in the middle of screen resize). If mc gets a better logging facility (right now only FTP is logged), that's something we may want to log. -- Regards, Pavel Roskin From proski at gnu.org Tue Jul 16 05:42:23 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 16 Jul 2002 01:42:23 -0400 (EDT) Subject: "Pause after run" && Scripts In-Reply-To: <20020715112948.18481B6D2@xmxpita.excite.com> Message-ID: Hi, David! On Mon, 15 Jul 2002, David Martin wrote: > It seems to be something about subshell changes. I've noticed this from > last snapshot (about one week old). We both were wrong. It's not about subshell changes. It's a result of the fact that the file associations (bindings) are now handled before executables, as requested by Abc Xyz in mc at devel.org. There was an rule for executable files in mc.ext. Those rules are not affected by the "pause after run" option, and that was fine in the past, when all executable files were executed internally. After moving the binding check before the internal execution, the rule became applicable to all files recognized by the "file" command as executables of some kind (binaries or scripts). Files with the double hash were not recognized as executables, so they were executed internally. I'm removing the rule for executable files from mc.ext. It always was a bad idea to rely on the "file" command to check which files are executable. Thank you for your bug report. -- Regards, Pavel Roskin From despair at sama.ru Thu Jul 18 06:02:46 2002 From: despair at sama.ru (Walery Studennikov) Date: Thu, 18 Jul 2002 11:02:46 +0500 Subject: sql.syntax Message-ID: <20020718110246.A2098@prog1.localdomain> Hello. New syntax highlighting file for SQL syntax can be downloaded from http://www.sama.ru/~despair/mc/sql.syntax.gz -- Regards, Walery From proski at gnu.org Thu Jul 18 16:45:10 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 18 Jul 2002 12:45:10 -0400 (EDT) Subject: sql.syntax In-Reply-To: <20020718110246.A2098@prog1.localdomain> Message-ID: Hello! > New syntax highlighting file for SQL syntax > can be downloaded from > http://www.sama.ru/~despair/mc/sql.syntax.gz Thank you! Applied after changing colors to be more C-like and adding support for MySQL comments ("--" to end of line) and PostgreSQL comments (between /* and */, exactly as in C). -- Regards, Pavel Roskin From reneb at cistron.nl Fri Jul 19 13:17:17 2002 From: reneb at cistron.nl (Rene Blokland) Date: Fri, 19 Jul 2002 15:17:17 +0200 Subject: ftp works mcftp noway Message-ID: <20020719131717.GA26009@orac.adsl.cistron.nl> Hello all, I have a problem, I want to make a homepage on the server of my ISP. I had to do it with "normal" ftp because mcftp won't let me. I have the latist CVS version When you look at the subdir WWW (see the log) it is empty! But there ARE 2 subdirs 1 is called maatjes. see "http.cistron.nl/~reneb/maatjes" Please help, thanks. -- Groeten / Regards, Rene J. Blokland -------------- next part -------------- GNU Midnight Commander 4.5.99a Virtual File System: tarfs, extfs, ftpfs, mcfs With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm -------------- next part -------------- 220 ProFTPD 1.2.4 Server (homepage.cistron.nl) [tuvix.cistron.net] MC -- remote_is_amiga = 0 USER reneb 331 Password required for reneb. PASS 230 User reneb logged in. PWD 257 "/extra/home/user/r/reneb" is current directory. PASV 227 Entering Passive Mode (62,216,31,71,153,62). TYPE A 200 Type set to A. LIST -la 150 Opening ASCII mode data connection for file list drwxr-xr-x 4 reneb users 4096 Jul 18 15:12 . drwxr-xr-x 244 root root 12288 Jul 18 12:51 .. -rw-r--r-- 1 reneb users 2312 May 23 1999 .bash_history -rw-r--r-- 1 reneb users 115 Jan 28 1998 .kermrc -rw-r--r-- 1 reneb users 25 Sep 1 2001 .newsrc drwxr-xr-x 2 reneb users 4096 Sep 1 2001 News drwxr-xr-x 4 reneb users 4096 Jul 18 15:14 WWW 226-Transfer complete. 226 Quotas off PASV 227 Entering Passive Mode (62,216,31,71,153,68). LIST -la /WWW/. 150 Opening ASCII mode data connection for file list 226-Transfer complete. 226 Quotas off PASV 227 Entering Passive Mode (62,216,31,71,153,75). TYPE I 200 Type set to I. RETR /.newsrc 550 /.newsrc: No such file or directory PASV 227 Entering Passive Mode (62,216,31,71,153,76). RETR /.newsrc 550 /.newsrc: No such file or directory QUIT From martin at internet-treff.uni-koeln.de Fri Jul 19 14:34:54 2002 From: martin at internet-treff.uni-koeln.de (Martin Bialasinski) Date: Fri, 19 Jul 2002 16:34:54 +0200 (CEST) Subject: ftp works mcftp noway In-Reply-To: <20020719131717.GA26009@orac.adsl.cistron.nl> Message-ID: On Fri, 19 Jul 2002, Rene Blokland wrote: Hi, > When you look at the subdir WWW (see the log) it is empty! > But there ARE 2 subdirs 1 is called maatjes. > see "http.cistron.nl/~reneb/maatjes" You can enable the ftp log using the "-l logfile" option. Maybe you can find out what is wrong this way. Ciao, Martin From proski at gnu.org Fri Jul 19 15:05:43 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 19 Jul 2002 11:05:43 -0400 (EDT) Subject: ftp works mcftp noway In-Reply-To: Message-ID: Hi, Martin! > > When you look at the subdir WWW (see the log) it is empty! > > But there ARE 2 subdirs 1 is called maatjes. > > see "http.cistron.nl/~reneb/maatjes" > > You can enable the ftp log using the "-l logfile" option. Maybe you can > find out what is wrong this way. The second attachment in Rene's message seems to be exactly that - the output of "mc -l mclog" Maybe you should consider using a better mail client. -- Regards, Pavel Roskin From proski at gnu.org Fri Jul 19 15:50:26 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 19 Jul 2002 11:50:26 -0400 (EDT) Subject: ftp works mcftp noway In-Reply-To: <20020719131717.GA26009@orac.adsl.cistron.nl> Message-ID: Hi, Rene! > I have a problem, I want to make a homepage on the server of my ISP. I > had to do it with "normal" ftp because mcftp won't let me. I have the > latist CVS version I appreciate it. This bug seems to be very recent. > When you look at the subdir WWW (see the log) it is empty! > But there ARE 2 subdirs 1 is called maatjes. > see "http.cistron.nl/~reneb/maatjes" > Please help, thanks. The log shows that mc thinks that it's in the root directory on the ftp server, but in fact it is not. I can reproduce this problem with wu-ftpd 2.6.1 on RedHat 7.2 in the default configuration when logging is as a ordinary user. Debugging shows that the result of ftpfs_get_current_directory() in vfs/ftpfs.c is assigned to SUP.home, but SUP.home is never used after that. It's clearly a bug and will be fixed. The workaround for now is to use the full path, i.e. you should enter this in the "FTP Link" query: homepage.cistron.nl/extra/home/user/r/reneb -- Regards, Pavel Roskin From xtango at netcombbs.com.ar Fri Jul 19 20:21:45 2002 From: xtango at netcombbs.com.ar (Ernesto) Date: Fri, 19 Jul 2002 17:21:45 -0300 Subject: Bug in VFS Message-ID: <200207191721.45643.xtango@netcombbs.com.ar> Hi, I want to report a bug in the VFS. I'm using MC to access an FTP server where I have a dir named "2002 - John Q". Here's how I see it from ncftp: ncftp /Peliculas > ls -l drwxr-xr-x 2 subidor subidor 4096 Jul 19 2002 2002 - John Q But when using MC, I only see " - John Q". MC eats the "2002" part from the dir name. I'm using MC 4.5.55 on Gentoo Linux 1.2 (kernel 2.4.19, glibc 2.2.5). The server is proftpd 1.2.5 (running on Linux as well). I guess this bug is easy to reproduce, but if you need any other information please let me know. Regards, Ernesto From proski at gnu.org Fri Jul 19 21:14:40 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 19 Jul 2002 17:14:40 -0400 (EDT) Subject: Bug in VFS In-Reply-To: <200207191721.45643.xtango@netcombbs.com.ar> Message-ID: Hello, Ernesto! > I want to report a bug in the VFS. I'm using MC to access an FTP server > where I have a dir named "2002 - John Q". Here's how I see it from > ncftp: > > ncftp /Peliculas > ls -l > drwxr-xr-x 2 subidor subidor 4096 Jul 19 2002 2002 - John Q > > But when using MC, I only see " - John Q". > MC eats the "2002" part from the dir name. I can reproduce this problem with the CVS version of MC. The first part of the filename is interpreted as year. This bug is hard to fix - the date parser in VFS is kludgy by design. There are many different FTP servers, and they use different formats for date. The problem with FTP servers (and the FTP protocol) is that there is no way to set the server to a particular locale. So the code must guess. In your case there is a simple solution, because no part of the date should repeat. We could add counters and work around it, but I doubt that it's worth the trouble. But let's consider this string: drwxr-xr-x 2 500 500 4096 Jul 19 17:01 2002 Q Is "2002" a year or a part of the filename? It may be either. Some FTP servers may print both the minutes and the year. If we only restrict the code to the servers that never print both the minutes and the year in the same timestamp, then it will be impossible to use such servers at all from mc. I think it's a high price to pay for support for some bizarre filenames. Date parsing needs more work, but I don't think it will happen soon until somebody produces a clean and well-documented patch. -- Regards, Pavel Roskin From proski at gnu.org Sat Jul 20 18:50:04 2002 From: proski at gnu.org (Pavel Roskin) Date: Sat, 20 Jul 2002 14:50:04 -0400 (EDT) Subject: Fix for keyword highlighting on the context boundary Message-ID: Hello, Paul! I have committed a patch for Midnight Commander that may be of some interest for you as the maintainer of Cooledit. It fixes a bug in the syntax highlighting engine, and I expect that Midnight Commander will soon use syntax highlighting rules that require this bug to be fixed. It would be nice if MC and Cooledit still could share syntax rules, so please apply this patch. I have tested it with Cooledit 3.17.5. The problem is that a keyword starting at the beginning of a context is not highlighted. Even though the new context starts, the keyword rule is not rechecked, despite what the comment in the code claims. Here's an example. I tried to use this in the rules for ChangeLog: context linestart \t \n\n keyword whole \t\* brightcyan/17 This is supposed to highlight every "*" after Tab. However, the first "*" in a group of indented lines is not highlighted due to the bug. ChangeLog: * syntax.c (apply_rules_going_right): Recheck keyword rules when a keyword is found on the left border of a context. ========================= --- syntax.c +++ syntax.c @@ -320,8 +320,10 @@ static inline struct syntax_rule apply_r _rule.border = RULE_ON_LEFT_BORDER; _rule._context = count; if (!r->between_delimiters) - if (!_rule.keyword) + if (!_rule.keyword) { _rule.context = count; + contextchanged = 1; + } break; } } ========================= By the way, please feel free to take rules from MC for Cooledit. Some files may need adding colors for Cooledit, but you could implement default colors based on their MC names, i.e. "yellow" or "yellow/" would mean "yellow/24" for Cooledit. -- Regards, Pavel Roskin From avarakin00 at hotmail.com Sun Jul 21 02:06:33 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Sat, 20 Jul 2002 22:06:33 -0400 Subject: CR/LF translation References: Message-ID: Hi, I changed mc to support CR/LF translation, patch is attached. It is very useful for cygwin and also useful under unixes if it is necessary to edit files in dos encoding. There is some old code in mc for CR/LF translation, but it is slow and based on FILE stdio.h interface, whereas editor now uses open/read/write interface. I wrote new code, which 1. reads file into buffer 2. determines type of file: dos or Unix, sets a new flag in WEdit structure accordingly 3. if file is dos, we allocate new buffer and copy the contents of first buffer to new buffer with conversion to Unix 4. status line now shows type of file 5. while saving file translate it back to dos , if it was dos There is an assumption that we are running on some decent 32 bit hardware because we are reading whole file into buffer for further translation. If 16 bit hardware detected, we just don't do translation. The second part of the patch fixes problems with CR in case if we are not using translation or if we have CR embedded in text . It works like vi with dos files: it shows CR as ^M. The original mc code handles CR very badly, it completely messes up files in dos encoding. Third part of patch fixes problem with dos text files on volumes mounted in text mode under cygwin. This problem is actually very dangerous because mc corrupts files in this case. Solution is to open all files in binary mode and do CR/LF translation. There was one instance of opening file with some strange MY_O_TEXT flag, I had to remove it because otherwise it may conflict with O_BINARY flag. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: CR_LF.patch Type: application/octet-stream Size: 14722 bytes Desc: not available URL: From ptsekov at gmx.net Sun Jul 21 05:52:22 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Sun, 21 Jul 2002 07:52:22 +0200 Subject: CR/LF translation In-Reply-To: References: Message-ID: <36563189.20020721075222@gmx.net> Hello Alexander, Sunday, July 21, 2002, 4:06:33 AM, you wrote: AV> I changed mc to support CR/LF translation, patch is attached. AV> It is very useful for cygwin and also useful under unixes if it is AV> necessary to edit files in dos encoding. I'll take a look at the patch ASAP, then I will release a test package of mc for Cygwin, so the people can test it and provide a feedback. Thanks! :) Pavel Tsekov From proski at gnu.org Sun Jul 21 17:02:41 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 21 Jul 2002 13:02:41 -0400 (EDT) Subject: FTP with non-root home Message-ID: Hello! The recent message by Rene Blokland shows that we have a long-standing problem that we cannot fix for years. I mean support for FTP servers, which set the initial directory to some other value than "/". I think we need some discussion before we start coding, otherwise we'll continue to break each other's code to "fix" the problem. I think there are 3 different approaches to solving this problem: 1) When /#ftp:server is requested, interpret it as "/#ftp:server/" and go to the root directory. This is consistent with fish and very easy to implement (just remove special handling for empty remote_path in dir_load()). The downside is that the user would have to return to the home directory, which name is not always as simple as /home/username. The workaround for the user is to do it once and record the directory to the hotlist. 2) Interpret "/#ftp:server" as the home directory on the remote server. The resulting directory with full path would become the current directory. This means that mc_chdir() won't always change the directory to exactly what was requested. In other words, you can call mc_chdir("/#ftp:server"), but the current directory will be "/#ftp:server/home/user" 3) Interpret symbol "~" as the home directory on the remote server. Expand "/#ftp:server" to "/#ftp:server/~/" before calling VFS level. I believe this was already tried and rejected because of complexity. This also can be confusing to the users. On the positive side, that's the only syntax that will allow paths like "/#ftp:server/~/tmp" without knowing the home directory. Comments and better ideas will be appreciated. -- Regards, Pavel Roskin From ptsekov at gmx.net Mon Jul 22 12:52:46 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 22 Jul 2002 14:52:46 +0200 Subject: 2002-07-10 changes in subshell.c In-Reply-To: References: Message-ID: <408702393.20020722145246@gmx.net> Hey, Pavel! :) PR> I understand there are two separate problems. One problem is that PR> TIOCSWINSZ doesn't work on pty as it should. Another problem is that it's PR> possible for ioctl() to return a non-zero value without errno becoming PR> non-zero. Not exactly. There are two problems with TIOCSWINSZ handling on pty childs: 1. ioctl() returns always -1 but leaves errno untouched. 2. TIOCSWINSZ doesn't work with pty childs :) Other than that ioctl()s on Cygwin return non-zero on error (-1), as on Linux, and set the errno appropriately. From reneb at cistron.nl Mon Jul 22 11:37:09 2002 From: reneb at cistron.nl (Rene J.Blokland) Date: Mon, 22 Jul 2002 13:37:09 +0200 Subject: FTP with non-root home Message-ID: <20020722133709.055bb573.reneb@cistron.nl> Hi Pavel! or solution no (4 Use Control X a You get a list in which you can find the Dir you want to use. Move the cursor on to that item an press enter. Now is is ok and add this link to your bookmarks and you'r ok! A nice thing to the FAQ! I can live with it! and is a quick solution because you have to do this seldom. -- Groeten / Regards, Rene J. Blokland From proski at gnu.org Mon Jul 22 16:09:35 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 22 Jul 2002 12:09:35 -0400 (EDT) Subject: FTP with non-root home In-Reply-To: <20020722133709.055bb573.reneb@cistron.nl> Message-ID: Hi, Rene! > Hi Pavel! or solution no (4 Use Control X a You get a list in which you > can find the Dir you want to use. Move the cursor on to that item an > press enter. Now is is ok and add this link to your bookmarks and you'r > ok! A nice thing to the FAQ! I can live with it! and is a quick solution > because you have to do this seldom. I think that's essentially the solution 2, but instead of calling mc_chdir() the second time with the adjusted directory, we tell the user to do it by hand. My experience shows that users who have their questions answered in the FAQ rarely (if ever) read it before asking in the mailing list. It's easier (hopefully, I haven't tried yet) to implement two step mc_chdir() than to reply everybody who asks. I believe the current behavior is a bug, and it should be fixed rather than documented. -- Regards, Pavel Roskin From nerijus at users.sourceforge.net Tue Jul 23 15:23:46 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Tue, 23 Jul 2002 17:23:46 +0200 (EET) Subject: ximian patches Message-ID: <200207231530.g6NFUoUi011542@mx.ktv.lt> Hello, Maybe some of them should be applied? http://patches.ximian.com/?selected_modules=mc&selected_branches=Ximian+GNOME+1.4&selected_platforms=redhat-73-i386&submit=Give+me+tha+patches%21#results http://patches.ximian.com/?selected_modules=mc&selected_branches=Ximian+GNOME+1.4&selected_platforms=debian-potato-i386&submit=Give+me+tha+patches%21#results Regards, Nerijus From proski at gnu.org Tue Jul 23 15:48:52 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 23 Jul 2002 11:48:52 -0400 (EDT) Subject: ximian patches In-Reply-To: <200207231530.g6NFUoUi011542@mx.ktv.lt> Message-ID: Hello, Nerijus! > Maybe some of them should be applied? Have you read those patched? I think the answer is obvious in most cases. > http://patches.ximian.com/?selected_modules=mc&selected_branches=Ximian+GNOME+1.4&selected_platforms=redhat-73-i386&submit=Give+me+tha+patches%21#results mc-4.5.35-xtermcolor.patch-1 - absolutely not. We have the right fix for color detection in CVS, and the whole list was removed a week ago. mc-4.5.36-mimekeys.patch-1 - GNOME-only, cannot be applied. mc-4.5.51-gnome-editor.patch-1 - GNOME-only. mc-no-string-inlines.patch-1 - I see no reason to disable string optimization. There is no comment why it should be done. > http://patches.ximian.com/?selected_modules=mc&selected_branches=Ximian+GNOME+1.4&selected_platforms=debian-potato-i386&submit=Give+me+tha+patches%21#results mc-fix-lib-makefile-am.patch-1 mc-mc-sysconfdir.patch-2 Those two patches move mc.global from /etc to /etc/mc. It should now be possible without patching anything, just by giving arguments to make. For that matter, the whole idea of mc.global is wrong. MC is a utility for users, and root has no business editing mc.global for them. All that stuff should eventually go to the local config file. -- Regards, Pavel Roskin From nerijus at users.sourceforge.net Tue Jul 23 15:58:01 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Tue, 23 Jul 2002 17:58:01 +0200 (EET) Subject: ximian patches In-Reply-To: References: Message-ID: <200207231600.g6NG0kUi020851@mx.ktv.lt> On Tue, 23 Jul 2002 11:48:52 -0400 (EDT) Pavel Roskin wrote: > mc-4.5.36-mimekeys.patch-1 - GNOME-only, cannot be applied. BTW, why my patch about adding mplayer for avi files, etc is still not applied? Regards, Nerijus From ptsekov at gmx.net Tue Jul 23 18:37:30 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 23 Jul 2002 20:37:30 +0200 Subject: [PATCH] copy_file_file: Use binary mode when opening the source/destination file Message-ID: <8228863633.20020723203730@gmx.net> The attached patch will help to avoid file coruption, as a result of a copy operation, between different mounted filesystems i.e. binary vs. text mounted filesystems. Thanks! :) Pavel Tsekov -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-copy_file_file.patch Type: application/octet-stream Size: 1039 bytes Desc: not available URL: From avarakin00 at hotmail.com Wed Jul 24 00:35:02 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Tue, 23 Jul 2002 20:35:02 -0400 Subject: [PATCH] copy_file_file: Use binary mode when opening the source/destination file References: <8228863633.20020723203730@gmx.net> Message-ID: It looks like we will end up adding O_BINARY flag to all mc_open calls (I did the same change for editor). Maybe it is a good idea to write mc_open as a wraper function (now it is macro) , and in this function always set O_BINARY, something like this: int mc_open(char * filename, int flags) { return open(filename, flags | O_BINARY); } Pavel R. , what do you think about this? ----- Original Message ----- From: "Pavel Tsekov" To: Sent: Tuesday, July 23, 2002 2:37 PM Subject: [PATCH] copy_file_file: Use binary mode when opening the source/destination file > The attached patch will help to avoid file coruption, as a result of a > copy operation, between different mounted filesystems i.e. binary vs. > text mounted filesystems. > > Thanks! :) > > Pavel Tsekov From ptsekov at gmx.net Wed Jul 24 11:39:57 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 24 Jul 2002 13:39:57 +0200 Subject: 2002-06-20 changes in dir.c Message-ID: <239945340.20020724133957@gmx.net> Hey, there! :) I found the following Changelog entry while I was investigating why I get a invalid date for a parent directory: 2002-06-20 Pavel Roskin * dir.c (handle_dirent): Don't process ".." entries. (handle_path): Likewise. From Andrew V. Samoilov I found a partial discussion in June that this would cause some kind of speedup. However I couldn't find the whole thread in the archives and the information there is not enough so I have to ask - how does this change cause a VFS speedup ? It seems the speedup will occur at some point after do_load_dir () is called i.e. when printing every single file entry. Then why do we have to skip the ".." in handle_dirent ? Skipping ".." in handle_direntry causes an invalid file_entry structure to be inserted later by add_dotdot_to_list () i.e. mtime, atime, permission, etc are not valid. If add_dotdot_to_list () puts some special information in the file_entry structure for the ".." is it posible just to set this piece of information along with the information returned by mc_readdir() for the parent directory ? Thanks! :) Pavel Tsekov From ptsekov at gmx.net Wed Jul 24 11:49:14 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 24 Jul 2002 13:49:14 +0200 Subject: [PATCH] copy_file_file: Use binary mode when opening the source/destination file In-Reply-To: References: <8228863633.20020723203730@gmx.net> Message-ID: <6710502051.20020724134914@gmx.net> Hey, Alexander! :) AV> It looks like we will end up adding O_BINARY flag to all mc_open calls (I AV> did the same change for editor). AV> Maybe it is a good idea to write mc_open as a wraper function (now it is AV> macro) , and in this function always set O_BINARY, something like this: AV> int mc_open(char * filename, int flags) AV> { AV> return open(filename, flags | O_BINARY); AV> } I thought about this but there may be code in mc which doesn't need this flag. I though that evaluating every single mc_open call and its purpose is the best way to decide which calls should have the O_BINARY flag set. After all there are not so much mc_open calls. I started looking at them but have not finished yet. From ptsekov at gmx.net Wed Jul 24 11:54:03 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 24 Jul 2002 13:54:03 +0200 Subject: CR/LF translation In-Reply-To: <36563189.20020721075222@gmx.net> References: <36563189.20020721075222@gmx.net> Message-ID: <11510790866.20020724135403@gmx.net> Hello Alexander, AV>> I changed mc to support CR/LF translation, patch is attached. AV>> It is very useful for cygwin and also useful under unixes if it is AV>> necessary to edit files in dos encoding. PT> I'll take a look at the patch ASAP, then I will release a test package PT> of mc for Cygwin, so the people can test it and provide a feedback. The patch seems ok to me and I will include it for the next Cygwin release of MC even if it is not included in the official source tree. Thanks! :) Pavel Tsekov From proski at gnu.org Thu Jul 25 15:28:30 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 25 Jul 2002 11:28:30 -0400 (EDT) Subject: ximian patches In-Reply-To: <200207231600.g6NG0kUi020851@mx.ktv.lt> Message-ID: Hello, Nerijus! > > mc-4.5.36-mimekeys.patch-1 - GNOME-only, cannot be applied. > > BTW, why my patch about adding mplayer for avi files, etc is still not applied? There are already associations for avi files. I don't want to change them without compelling reasons. But I have some patches from Michal Svec that make mc.ext more flexible, and they will be applied when I find time to test them, possibly after 4.6.0 release. -- Regards, Pavel Roskin From nerijus at users.sourceforge.net Thu Jul 25 15:44:02 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Thu, 25 Jul 2002 17:44:02 +0200 (EET) Subject: ximian patches In-Reply-To: References: Message-ID: <200207251550.g6PFopUi010555@mx.ktv.lt> On Thu, 25 Jul 2002 11:28:30 -0400 (EDT) Pavel Roskin wrote: > > BTW, why my patch about adding mplayer for avi files, etc is still not applied? > > There are already associations for avi files. I don't want to change them > without compelling reasons. Of course there are. But xanim does not play most new avi's, including divx, while mplayer plays everything and can even use xanim's codecs. gtv is just a sample application from smpeg sources, it was probably added because at that time there were no other decent players (actually earlier instead of gtv commercial mtvp was used). So IMHO these are compelling reasons. Please change both avi and mpg to use mplayer. Regards, Nerijus From roland.illig at gmx.de Fri Jul 26 17:14:40 2002 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 26 Jul 2002 17:14:40 +0000 Subject: patch for the viewer in mc-4.5.99 Message-ID: <02072617144000.00876@roland> The patch adds more strictness to the nroff parser. As a result, binary files will contain less "bold" letters than before. It is appendended because of the line breaks that occur in mails. It looks like: --- mc-4.5.99a.old/src/view.c 2002-07-20 06:13:16.000000000 +0200 +++ mc-4.5.99a/src/view.c 2002-07-26 18:54:53.000000000 +0200 @@ -972,7 +972,10 @@ if (from + 1 < view->last_byte && is_printable (get_byte (view, from + 1)) && from > view->first - && is_printable (get_byte (view, from - 1))) + && is_printable (get_byte (view, from - 1)) && + (get_byte(view, from + 1) == get_byte(view, from - 1) + || get_byte(view, from + 1) == '_' + || get_byte(view, from - 1) == '_')) { if (col <= frame_shift){ /* So it has to be wrap_mode - do not need to check for it */ @@ -1007,10 +1010,11 @@ c = conv_displ[ c ]; #endif - if (!is_printable (c)) - c = '.'; - - view_add_character (view, c); + if (!is_printable (c)){ + view_add_character(view, '.'); + } else{ + view_add_character (view, c); + } } col++; if (boldflag){ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-4.5.99-viewer.patch Type: text/x-diff Size: 948 bytes Desc: not available URL: From proski at gnu.org Fri Jul 26 17:20:09 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 26 Jul 2002 13:20:09 -0400 (EDT) Subject: patch for the viewer in mc-4.5.99 In-Reply-To: <02072617144000.00876@roland> Message-ID: Hi, Roland! > The patch adds more strictness to the nroff parser. As a result, > binary files will contain less "bold" letters than before. Thanks! Applied after massive changes. > - && is_printable (get_byte (view, from - 1))) > + && is_printable (get_byte (view, from - 1)) && > + (get_byte(view, from + 1) == get_byte(view, > from - 1) > + || get_byte(view, from + 1) == '_' This case (symbol, backspace, underscore) doesn't work, as you could have noticed if you had tested your patch a little bit more. MC displays bold underscore. It never worked right. Adding proper support for this would require quite a lot of code, and is not worth the trouble, since nroff always puts the underscore before the backspace. Now this case is not interpreted, which is much better than a string of underscores. The number of get_byte() calls becomes too large, so I added two variables to hold the previous and the next character. > - if (!is_printable (c)) > - c = '.'; > - > - view_add_character (view, c); > + if (!is_printable (c)){ > + view_add_character(view, '.'); > + } else{ > + view_add_character (view, c); > + } I believe, this part is not necessary, so I removed it. -- Regards, Pavel Roskin From gnome-devel at deaddog.org Sat Jul 27 00:00:41 2002 From: gnome-devel at deaddog.org (R.I.P. Deaddog) Date: Sat, 27 Jul 2002 08:00:41 +0800 (HKT) Subject: ximian patches In-Reply-To: <200207251550.g6PFopUi010555@mx.ktv.lt> Message-ID: On 2002-07-25(Thu) 17:44:02 +0200, Nerijus Baliunas wrote: > On Thu, 25 Jul 2002 11:28:30 -0400 (EDT) Pavel Roskin wrote: > > > > BTW, why my patch about adding mplayer for avi files, etc is still not applied? > > > > There are already associations for avi files. I don't want to change them > > without compelling reasons. > > Of course there are. But xanim does not play most new avi's, including divx, > while mplayer plays everything and can even use xanim's codecs. gtv is just > a sample application from smpeg sources, it was probably added because at > that time there were no other decent players (actually earlier instead of > gtv commercial mtvp was used). So IMHO these are compelling reasons. Please > change both avi and mpg to use mplayer. Yup, I'd agree too that mplayer is one of the best video player out there, much better than the xanim, gtv etc... > Regards, > Nerijus -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc From dmartina at excite.com Sun Jul 28 00:24:25 2002 From: dmartina at excite.com (David Martin) Date: Sat, 27 Jul 2002 20:24:25 -0400 (EDT) Subject: Spanish translations update Message-ID: <20020728002425.EBC02B6EF@xmxpita.excite.com> Just one single string. The patch should fit both es.po and es_ES.po. *8-) David ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: es.diff URL: From avarakin00 at hotmail.com Sun Jul 28 03:42:57 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Sat, 27 Jul 2002 23:42:57 -0400 Subject: mc-4.5.55 is now part of the Cygwin net distribution References: Message-ID: > > Any luck with subshell under cygwin? > > Actually if I run mc inside a DOS box, the subshell works reasonably well. > > It hangs only if I run it inside rxvt. > > It hangs for me the DOS box. Any progress with subshell problem? Is anybody looking at this problem? Alex From esr at golux.thyrsus.com Fri Jul 26 16:03:29 2002 From: esr at golux.thyrsus.com (Eric S. Raymond) Date: Fri, 26 Jul 2002 12:03:29 -0400 Subject: Bug on the mc.1 manual page Message-ID: <200207261603.g6QG3Tu28981@golux.thyrsus.com> --- mc.1 2002/07/26 16:01:40 1.1 +++ mc.1 2002/07/26 16:01:46 @@ -437,7 +437,7 @@ .B M-u Moves to the next directory in the history, equivalent to depressing the '>' with the mouse. -.BM-S-h, M-H +.B M-S-h, M-H Displays the directory history, equivalent to depressing the 'v' with the mouse. .PP -- Eric S. Raymond Probably fewer than 2% of handguns and well under 1% of all guns will ever be involved in a violent crime. Thus, the problem of criminal gun violence is concentrated within a very small subset of gun owners, indicating that gun control aimed at the general population faces a serious needle-in-the-haystack problem. -- Gary Kleck, "Point Blank: Handgun Violence In America" From proski at gnu.org Sun Jul 28 06:40:32 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 28 Jul 2002 02:40:32 -0400 (EDT) Subject: Bug on the mc.1 manual page In-Reply-To: <200207261603.g6QG3Tu28981@golux.thyrsus.com> Message-ID: Hello, Eric! > -.BM-S-h, M-H > +.B M-S-h, M-H Already fixed in CVS. Thank you! -- Regards, Pavel Roskin From proski at gnu.org Sun Jul 28 06:47:44 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 28 Jul 2002 02:47:44 -0400 (EDT) Subject: Spanish translations update In-Reply-To: <20020728002425.EBC02B6EF@xmxpita.excite.com> Message-ID: On Sat, 27 Jul 2002, David Martin wrote: > Just one single string. The patch should fit both es.po and es_ES.po. Thanks, applied! -- Regards, Pavel Roskin From proski at gnu.org Sun Jul 28 09:24:31 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 28 Jul 2002 05:24:31 -0400 (EDT) Subject: ximian patches In-Reply-To: Message-ID: Hello! > Yup, I'd agree too that mplayer is one of the best video player out > there, much better than the xanim, gtv etc... Maybe you don't understand the problem. It's easy to support alternate commands if all of them (except the last one) will almost always return code 0. So if we get something else, it usally means that the command is missing or failed completely, so we can try the next command. This is what mc does for MS-Word documents: regex/\.([Dd]o[ct]|DO[CT]|[Ww]ri|WRI)$ View=%view{ascii} catdoc -w %f || word2x -f text %f - || strings %f Even if catdoc exists and fails, it's just fine to try word2x, because it may have some chances to succeed. And if both fail, we always have strings, which should always work. We cannot do this with video players. A player can crash in the middle of stream on a broken frame. We shouldn't start another player that would play from the beginning - if would be very annoying for those who have both players. This means that without changes in the code, the only solution is to comment out xanim. This also means that the users who have xanim but not mplayer will find after upgrade that they have to edit the extension file to restore the functionality they had. Compile time detection is not a solution - most users don't compile their software. Perhaps the best solution would be to allow more than one Open entry and make mc select the best of them based on environment (running in X or not), presence of some executables in PATH and possibly other factors. A patch was posted in this list that introduces XOpen - a variant of Open that works in X11. I haven't seen any discussion about this patch. It's a much more generic approach, but it still doesn't include check for PATH. Recommended reading: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING -- Regards, Pavel Roskin From proski at gnu.org Sun Jul 28 20:25:47 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 28 Jul 2002 16:25:47 -0400 (EDT) Subject: mc-4.5.55 is now part of the Cygwin net distribution In-Reply-To: Message-ID: On Sat, 27 Jul 2002, Alexander Varakin wrote: > > > Any luck with subshell under cygwin? > > > Actually if I run mc inside a DOS box, the subshell works reasonably > well. > > > It hangs only if I run it inside rxvt. > > > > It hangs for me the DOS box. > > Any progress with subshell problem? > Is anybody looking at this problem? Not me. I only have Windows at work, and I have other things to do there. -- Regards, Pavel Roskin From proski at gnu.org Sun Jul 28 20:35:26 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 28 Jul 2002 16:35:26 -0400 (EDT) Subject: [PATCH] copy_file_file: Use binary mode when opening the source/destination file In-Reply-To: Message-ID: On Tue, 23 Jul 2002, Alexander Varakin wrote: > It looks like we will end up adding O_BINARY flag to all mc_open calls (I > did the same change for editor). > Maybe it is a good idea to write mc_open as a wraper function (now it is > macro) , and in this function always set O_BINARY, something like this: > int mc_open(char * filename, int flags) > { > return open(filename, flags | O_BINARY); > } > > Pavel R. , what do you think about this? This would essentially force using VFS under Cygwin. mc_open() is the same as open() if VFS is disabled. If we do such hacks, it will be harder to replace our VFS with GNOME VFS when the later is ready. Maybe we can introduce another level of redirection, so that mc_open() would go to src/ and would do some useful things like adding O_BINARY and then would call either open() or vfs_open() dependent on whether VFS is enabled. Whatever is cuttently called mc_open() would become vfs_open(). -- Regards, Pavel Roskin From proski at gnu.org Sun Jul 28 20:40:20 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 28 Jul 2002 16:40:20 -0400 (EDT) Subject: 2002-06-20 changes in dir.c In-Reply-To: <239945340.20020724133957@gmx.net> Message-ID: Hello! > I found a partial discussion in June that this would cause some kind > of speedup. However I couldn't find the whole thread in the archives > and the information there is not enough so I have to ask - how does > this change cause a VFS speedup ? It seems the speedup will occur > at some point after do_load_dir () is called i.e. when printing every > single file entry. Then why do we have to skip the ".." in > handle_dirent ? Skipping ".." in handle_direntry causes an invalid file_entry > structure to be inserted later by add_dotdot_to_list () i.e. mtime, > atime, permission, etc are not valid. If add_dotdot_to_list () puts > some special information in the file_entry structure for the ".." is > it posible just to set this piece of information along with the > information returned by mc_readdir() for the parent directory ? Not sure if I understand you, but the whole idea is not read the parent directory. Don't assume that it's cashed. If I go straight to server:/home/user from the hotlist, server:/home is not cached, and it can be a huge directory. -- Regards, Pavel Roskin From proski at gnu.org Sun Jul 28 22:11:30 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 28 Jul 2002 18:11:30 -0400 (EDT) Subject: CR/LF translation In-Reply-To: Message-ID: Hello! > I changed mc to support CR/LF translation, patch is attached. > It is very useful for cygwin and also useful under unixes if it is > necessary to edit files in dos encoding. > There is some old code in mc for CR/LF translation, but it is slow and based > on FILE stdio.h interface, whereas editor now uses open/read/write > interface. > I wrote new code, which > 1. reads file into buffer This is unacceptable. As of now, the editor never loads the whole file - it uses buffers. The viewer, however, tries to mmap() the whole file and if mmap() fails, loads the whole file into the memory. Loading the whole file is known to use too much resources. Besides, this imposes a 4 Gb limit on the file size on 32-bit systems. Several people complained about this limit in the viewer, so there will be complaints about the editor. Your code suggests that if sizeof(int) is 4 or more, any file can be loaded. That's not true. Firstly, int is irrelevant here. What's relevant is pointer to char. Nobody forces you to use int to index memory - you can use long, which can always hold a pointer. Secondly, even long is 32-bit on 32-bit platforms, which imposes a 4 Gb limit on the files. You can read any point in the file using off_t type, which becomes a 64-bit integer if large file support is enabled. However, you cannot load the whole file and work with it in memory, because you would have to use standard pointers. > 4. status line now shows type of file The type doesn't fit to the screen on 80x25 terminals. Also, having "UNIX" on screen almost all the time I'm editing something is not nice - "UNIX" is a trademark. "LF" would be better. > 5. while saving file translate it back to dos , if it was dos There is > an assumption that we are running on some decent 32 bit hardware because > we are reading whole file into buffer for further translation. If 16 bit > hardware detected, we just don't do translation. Please find somewhere a definition of 32-bit hardware. > The second part of the patch fixes problems with CR in case if we are > not using translation or if we have CR embedded in text . It works like > vi with dos files: it shows CR as ^M. The original mc code handles CR > very badly, it completely messes up files in dos encoding. Could you please explain it in detail? I'm not aware of any problems. Maybe this part can be applied separately? > Third part of patch fixes problem with dos text files on volumes mounted > in text mode under cygwin. This problem is actually very dangerous > because mc corrupts files in this case. Solution is to open all files in > binary mode and do CR/LF translation. There was one instance of opening > file with some strange MY_O_TEXT flag, I had to remove it because > otherwise it may conflict with O_BINARY flag. Yes, MY_O_TEXT should be removed. I think it should be possible to set binary more by default for the whole process. You can find this line in main.c, which is used for EMX (actually, for RSX, because we are not supporting OS/2 anymore): _fmode = O_BINARY; Maybe there is something similar for Cygwin? -- Regards, Pavel Roskin From ptsekov at gmx.net Mon Jul 29 09:54:43 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 29 Jul 2002 11:54:43 +0200 (MEST) Subject: 2002-06-20 changes in dir.c References: Message-ID: <22434.1027936483@www15.gmx.net> > > I found a partial discussion in June that this would cause some kind > > of speedup. However I couldn't find the whole thread in the archives > > and the information there is not enough so I have to ask - how does > > this change cause a VFS speedup ? It seems the speedup will occur > > at some point after do_load_dir () is called i.e. when printing every > > single file entry. Then why do we have to skip the ".." in > > handle_dirent ? Skipping ".." in handle_direntry causes an invalid > file_entry > > structure to be inserted later by add_dotdot_to_list () i.e. mtime, > > atime, permission, etc are not valid. If add_dotdot_to_list () puts > > some special information in the file_entry structure for the ".." is > > it posible just to set this piece of information along with the > > information returned by mc_readdir() for the parent directory ? > > Not sure if I understand you, but the whole idea is not read the parent If you run a snapshot of MC and change the 'Listing mode' to 'Full file list' you will most likely see that the '..' entry will contain an invalid entry in the 'MTime' column. Does this make the problem more obvious ? I suppose you're aware of that fact anyway, but it's not cool to have invalid data for the parent directory entry IMO. > directory. Don't assume that it's cashed. If I go straight to > server:/home/user from the hotlist, server:/home is not cached, and it can > > be a huge directory. Ok I can imagine that, but isn't it better to speed up (somhow) the remote file system 'stat' instead of just dropping specific entries from processing ? I haven't looked at the details of how the remote stat works for any of the supported filesystems but I intend to do so and if I come up with something I'll put it for discussion on the list . Thanks! :) Pavel Tsekov -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From ptsekov at gmx.net Mon Jul 29 09:56:54 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 29 Jul 2002 11:56:54 +0200 (MEST) Subject: mc-4.5.55 is now part of the Cygwin net distribution References: Message-ID: <27496.1027936614@www15.gmx.net> > > Any progress with subshell problem? > > Is anybody looking at this problem? > > Not me. I only have Windows at work, and I have other things to do there. I'm back from vacation, so I'll be working on that. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From ptsekov at gmx.net Mon Jul 29 10:02:08 2002 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 29 Jul 2002 12:02:08 +0200 (MEST) Subject: [PATCH] copy_file_file: Use binary mode when opening the source/destination file References: Message-ID: <8210.1027936928@www15.gmx.net> > > Maybe it is a good idea to write mc_open as a wraper function (now it > is > > macro) , and in this function always set O_BINARY, something like this: > > int mc_open(char * filename, int flags) > > { > > return open(filename, flags | O_BINARY); > > } > > > > Pavel R. , what do you think about this? > > This would essentially force using VFS under Cygwin. mc_open() is the > same as open() if VFS is disabled. > > If we do such hacks, it will be harder to replace our VFS with GNOME VFS > when the later is ready. There is another way to do this on Cygwin, but it is a bit hackish too.. You can link a special object file provided by Cygwin (binmode.o) which will make the resulting executable to open all the files in binary mode. As I say in a my previous mail isn't it better to evaluate all open () calls and decide which of them would need to be added the O_BINARY flag ? -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From dmartina at excite.com Mon Jul 29 17:47:39 2002 From: dmartina at excite.com (David Martin) Date: Mon, 29 Jul 2002 13:47:39 -0400 (EDT) Subject: Web editing with mc Message-ID: <20020729174739.06E923DF0@xmxpita.excite.com> I use MC as the main tool in the maintenance of our web site. There are some changes I would propose. I know they can be done by users themselves in their user directories, but I think that most of them could do as defaults. Let's go: 1) The HTML syntax file may be better but it's quite useful. It's been written with uppercase tags and it can be converted to lowercase as stated at the head of the file. HTML is case insensitive, but new XHTML requires lowercase tags. I would convert the file to show lowercase tags (I do it everyday for myself when installing the latest snapshot) and let the user change it to uppercase if preferred. 2) Clean HTML. I use the tidy program found at W3C: http://www.w3.org/People/Raggett/tidy/ I have .mc.menu files spread all over the site with: + ! t t l Tidy blah, blah, blah... tidy -ascii -m -wrap 80 ./%0f 2> err.txt It would be nice to have this as a standard filter in the editor (edit.indent.rc), sort of: htm|html|HTM|HTML) # http://www.w3.org/People/Raggett/tidy/ tidy -m -ascii -wrap 80 -f "tidy-$1.log" "$2" ;; Standard error is sent to a log file as it may give some useful information on the changes done. That's the best choice I got yesterday. 3) About edit.indent.rc. It seems that if any error message is received changes are ignored and the message goes to the editing block. Wouldn't it be better to keep the warning/error in the console before the "Press key" message and maybe have a flag to be used as the error value of the script and to tell mcedit if the buffer ($2) can be used? (removed 2 "exec" lines) case ....... ........... esac 2>"$3" >/dev/null more "$3" exit $ERR ... and use this ERR value instead of just checking the presence of the cooledit error file. (Maybe some of these have already been improved in Cooledit?) 4) Viewers: What about trying "links" before "lynx"? I hope you like them. Little coding and new features. *8-) David ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! From nerijus at users.sourceforge.net Mon Jul 29 17:58:49 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 29 Jul 2002 19:58:49 +0200 (EET) Subject: Web editing with mc In-Reply-To: <20020729174739.06E923DF0@xmxpita.excite.com> References: <20020729174739.06E923DF0@xmxpita.excite.com> Message-ID: <200207291801.g6TI11Ui007189@mx.ktv.lt> On Mon, 29 Jul 2002 13:47:39 -0400 (EDT) David Martin wrote: > 4) Viewers: What about trying "links" before "lynx"? I think I sent a patch for that some time ago. BTW, Pavel changed avi/mpg to mplayer, thanks! Regards, Nerijus From sav at bcs.zp.ua Tue Jul 30 21:50:35 2002 From: sav at bcs.zp.ua (Andrew V. Samoilov) Date: Wed, 31 Jul 2002 00:50:35 +0300 Subject: gindex.pl can be eliminated by man2hlp now Message-ID: <20020730215035.GA27710@bcs.zp.ua> Hi! This patch eliminates gindex.pl, new syntax is man2hlp width manfile template_file mc.hlp_file. It preserves old behaviour if man2hlp is called with exactly 3 arguments. So, there are no needs for lib/mc.hlp and lib/mc.ru in the source tarball. -- Regards, Andrew V. Samoilov --- man2hlp.c~ Thu Mar 21 15:01:20 2002 +++ man2hlp.c Wed Jul 31 00:32:40 2002 @@ -20,6 +20,10 @@ #include #include #include + +#include /* O_RDONLY, O_WRONLY */ +#include /* FIXME: we need HAVE_UNISTD_H or so on */ + #include "help.h" #define BUFFER_SIZE 256 @@ -38,6 +42,15 @@ static int link_flag = 0; /* Flag: Next static int verbatim_flag = 0; /* Flag: Copy input to output verbatim */ static int node = 0; /* Flag: This line is an original ".SH" */ +static char *output; /* The name of the output mc.hlp */ +static char *Topics = "Topics:"; + +static struct node { + char *node; + char *lname; + struct node *next; +} nodes, *cnode; + /* Report error in input */ static void print_error (char *message) { @@ -214,11 +227,27 @@ static void handle_command (char *buffer else { if (!SH || !node){ /* Start a new section */ + if (!output) printf ("%c[%s]", CHAR_NODE_END, buffer); + else { + printf ("%c[%s]", CHAR_NODE_END, buffer + heading_level); + if (!cnode){ + cnode = &nodes; + cnode->next = NULL; + } else { + cnode->next = malloc (sizeof (nodes)); + cnode = cnode->next; + } + cnode->node = strdup (buffer); + cnode->lname = NULL; + } col ++; newline (); } if (SH){ + if (output) + /* print_string() strtok()es buffer, so */ + cnode->lname = strdup (buffer + heading_level); print_string (buffer + heading_level); newline (); newline (); @@ -291,7 +320,10 @@ static void handle_command (char *buffer print_error ("Syntax error: .\\\"TOPICS: no text"); return; } - printf ("%s\n", buffer); + if (output) + Topics = strdup (buffer); + else + printf ("%s\n", buffer); } else { /* Other commands are ignored */ @@ -340,13 +372,20 @@ int main (int argc, char **argv) FILE *file; /* Input file */ char buffer2 [BUFFER_SIZE]; /* Temp input line */ char *buffer = buffer2; /* Input line */ + char *node = NULL; + + int file_fd; + long contents_beginning, file_end; /* Validity check for arguments */ - if (argc != 3 || ((width = atoi (argv[1])) <= 10)){ - fprintf (stderr, "Usage: man2hlp \n"); + if ((argc != 3 && argc != 5) || ((width = atoi (argv[1])) <= 10)){ + fprintf (stderr, "Usage: man2hlp [template_file helpfile]\n"); return 3; } + if (argc == 5) + output = argv[4]; + /* Open the input file */ filename = argv[2]; file = fopen (filename, "r"); @@ -356,6 +395,12 @@ int main (int argc, char **argv) return 3; } + if (argc == 5 && freopen (argv [4], "w", stdout) == NULL){ + sprintf (buffer, "man2hlp: Cannot open file \"%s\"", argv[4]); + perror (buffer); + return 3; + } + /* Repeat for each input line */ while (!feof (file)){ /* Read a line */ @@ -399,5 +444,94 @@ int main (int argc, char **argv) /* All done */ newline (); fclose (file); + + if (argc != 5) + return 0; + + /* Open the template file */ + filename = argv[3]; + file = fopen (filename, "r"); + if (file == NULL){ + sprintf (buffer, "man2hlp: Cannot open file \"%s\"", filename); + perror (buffer); + return 3; + } + /* Repeat for each input line */ + while (!feof (file)){ + /* Read a line */ + if (!fgets (buffer2, BUFFER_SIZE, file)){ + break; + } + if (node){ + if (*buffer2 && *buffer2 != '\n'){ + cnode->lname = strdup (buffer2); + node = strchr (cnode->lname, '\n'); + if (node) + *node = 0; + } + node = NULL; + } else { + node = strchr (buffer, CHAR_NODE_END); + if (node && (*(node+1) == '[')){ + char *p = strrchr (node, ']'); + if (p && strncmp (node+2, "main", 4) == 0 && *(node + 6) == ']') { + node = 0; + } else { + if (!cnode){ + cnode = &nodes; + cnode->next = NULL; + } else { + cnode->next = malloc (sizeof (nodes)); + cnode = cnode->next; + } + cnode->node = strdup (node + 2); + cnode->node [p - node - 2] = 0; + cnode->lname = NULL; + } + } else + node = NULL; + } + fputs (buffer, stdout); + } + + contents_beginning = ftell (stdout); + printf ("\004[Contents]\n%s\n\n", Topics); + + for (cnode = &nodes; cnode && cnode->node; cnode = cnode->next){ + char *node = cnode->node; + int heading_level = 0; + while (*node == ' '){ + heading_level++; + node++; + } + if (*node) + printf (" %*s\001 %s \002%s\003", heading_level, "", + cnode->lname ? cnode->lname : node, + node); + printf ("\n"); + + free (cnode->node); + if (cnode->lname) + free (cnode->lname); + if (cnode != &nodes) + free (cnode); + } + + file_end = ftell (stdout); + fclose (file); + + Topics = malloc (file_end); + file_fd = open (output, O_RDONLY); + if (file_fd == -1) + perror (output); + if (read (file_fd, Topics, file_end) != file_end) + perror (output); + if (close (file_fd) == -1) + perror (output); + file_fd = open (output, O_WRONLY); + write (file_fd, Topics + contents_beginning, file_end - contents_beginning); + write (file_fd, Topics, contents_beginning); + close (file_fd); + return 0; } From proski at gnu.org Tue Jul 30 22:38:11 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 30 Jul 2002 18:38:11 -0400 (EDT) Subject: gindex.pl can be eliminated by man2hlp now In-Reply-To: <20020730215035.GA27710@bcs.zp.ua> Message-ID: Hello! > This patch eliminates gindex.pl, new syntax is > man2hlp width manfile template_file mc.hlp_file. > > It preserves old behaviour if man2hlp is called with exactly 3 arguments. Great! Thank you! It should have been done long ago. Applied with necessary changes to the makefiles. > So, there are no needs for lib/mc.hlp and lib/mc.ru in the source tarball. This will be the next step. I want to check portability of the new code at least on some OSes first. Nitpicking: 1) Use free() for Topics 2) Use high-level file I/O if possible 3) perror() doesn't stop execution I'm fixing it right now. -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 31 04:33:37 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 31 Jul 2002 00:33:37 -0400 (EDT) Subject: Valgrind vs. MAD Message-ID: Hello! Valgrind 1.0.0 has been released. It's a memory debugger to x86 Linux. More details here http://developer.kde.org/~sewardj/ Testing CVS mc with Valgrind in the default mode exhibited 3 bugs: 1) Matching for "shell" rules in ext.c was reading memory before the filename if it was shorter than the extension being matched against it. Fixed. 2) Undo buffer in the editor is not initialized. However, the undo stack pointer can wrap to the end of the buffer in edit_push_action(), thus using unitialized data as the base for event compression. Pending investigation. 3) There are some messages about incorrect use of getgrnam() in vfs/names.c:118. Possibly bogus. The warning goes away if mc is compiled by gcc-3.1 (it's usually gcc-2.96 from RedHat). Using additional switches, it's possible to make Valgrind find memory leaks. It does it much better than MAD because it knows which pointers are still used and which have been lost. Although Valgrind is currently limited to one OS and one architecture, it does such a great job, that we should consider removing MAD (memory allocation debugger) from the MC sources. Memory leaks are usually the same on different architectures, and that's the only thing MAD can do. I believe that it's better to direct potential testers to a tool that works well, rather than confuse them by keeping an old, less capable MAD. As for distinguishing between g_malloc() and malloc(), it can be done with Valgrind by redirecting malloc() and free() to some alternative memory manager while keeping g_* functions intact. I don't think it's worth the trouble to distinguish between g_malloc() and malloc(), as long as we stay with glib-1.2. -- Regards, Pavel Roskin From proski at gnu.org Wed Jul 31 05:30:36 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 31 Jul 2002 01:30:36 -0400 (EDT) Subject: Web editing with mc In-Reply-To: <20020729174739.06E923DF0@xmxpita.excite.com> Message-ID: Hi, David! > I use MC as the main tool in the maintenance of our web site. There are > some changes I would propose. I know they can be done by users > themselves in their user directories, but I think that most of them > could do as defaults. > > Let's go: > > 1) The HTML syntax file may be better but it's quite useful. It's been > written with uppercase tags and it can be converted to lowercase as > stated at the head of the file. HTML is case insensitive, but new XHTML > requires lowercase tags. I would convert the file to show lowercase tags > (I do it everyday for myself when installing the latest snapshot) and > let the user change it to uppercase if preferred. It's currently the largest syntax file by a wide margin. I don't think MC should distinguish valid and invalid tags - there are too many of them, not to mention the attributes. There are validators that do their job. MC is not an HTML validator. In particular, uppercase tags are perfectly OK in HTML 3.2. I believe that mc should highlight only syntax, not names, unless the later are some very common keywords. I think the whole html.syntax should be rewritten and simplified. By the way, maybe we should hightlight "<" and ">" with a separate color in the opening and closing tags respectively? > It would be nice to have this as a standard filter in the editor > (edit.indent.rc), sort of: > > htm|html|HTM|HTML) > # http://www.w3.org/People/Raggett/tidy/ > tidy -m -ascii -wrap 80 -f "tidy-$1.log" "$2" > ;; Maybe. > Standard error is sent to a log file as it may give some useful > information on the changes done. That's the best choice I got yesterday. > > 3) About edit.indent.rc. It seems that if any error message is received > changes are ignored and the message goes to the editing block. Wouldn't > it be better to keep the warning/error in the console before the "Press > key" message and maybe have a flag to be used as the error value of the > script and to tell mcedit if the buffer ($2) can be used? Maybe it would be better, but the number of dirty hacks in mc is absolutely incredible, and the number of people fixing them is very small. I have to choose what to fix first. > 4) Viewers: What about trying "links" before "lynx"? Rearranging associations for html files is one of my high priority tasks before the release. Yes, links will be first if DISPLAY is unset, unless I find any problems with it. -- Regards, Pavel Roskin From dmartina at excite.com Wed Jul 31 10:59:42 2002 From: dmartina at excite.com (David Martin) Date: Wed, 31 Jul 2002 06:59:42 -0400 (EDT) Subject: Web editing with mc Message-ID: <20020731105942.4D0513CDF@xmxpita.excite.com> --- On Wed 07/31, Pavel Roskin wrote: > It's currently the largest syntax file by a wide margin. I don't think > MC > should distinguish valid and invalid tags - there are too many of them, > not to mention the attributes. There are validators that do their job. > MC is not an HTML validator. In particular, uppercase tags are perfectly > OK in HTML 3.2. > 100% OK. Lowercase tags are perfectly OK in HTML 3.2, but the newer XHTML 1.0 requires lowercase. I think people tend to use lowercase so that's why I proposed to "tr-anslate" the syntax file. > I believe that mc should highlight only syntax, not names, unless the > later are some very common keywords. I think the whole html.syntax > should > be rewritten and simplified. By the way, maybe we should hightlight > " and ">" with a separate color in the opening and closing > tags > respectively? > Hmm! Maybe it needs some rewriting but HTML is getting quite complex. MC should do a minimal highlighting just to help a bit. Style blocks in HTML files may be highligted but there were problems with contexts within other contexts. I wouldn't mind spending some time this summer on this. I did the .po syntax file but now I may need some recycling. > > It would be nice to have this as a standard filter in the editor > > (edit.indent.rc), sort of: > > > > htm|html|HTM|HTML) > > # http://www.w3.org/People/Raggett/tidy/ > > tidy -m -ascii -wrap 80 -f "tidy-$1.log" > "$2" > > ;; > > Maybe. > Hmm!? Explain "maybe". Does is mean "Don't bother any more", "ASAP", "I have to think about it", "I'm too busy and it's been queued"? No complains. Just kidding a bit :) > > Standard error is sent to a log file as it may give some useful > > information on the changes done. That's the best choice I got > yesterday. > > > > 3) About edit.indent.rc. It seems that if any error message is > received > > changes are ignored and the message goes to the editing block. > Wouldn't > > it be better to keep the warning/error in the console before the > "Press > > key" message and maybe have a flag to be used as the error value > of the > > script and to tell mcedit if the buffer ($2) can be used? > > Maybe it would be better, but the number of dirty hacks in mc is > absolutely incredible, and the number of people fixing them is very small. > > I have to choose what to fix first. > > > 4) Viewers: What about trying "links" before > "lynx"? > > Rearranging associations for html files is one of my high priority tasks > before the release. Yes, links will be first if DISPLAY is unset, unless > > I find any problems with it. > > -- > Regards, > Pavel Roskin > *8-) David ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! -------------- next part -------------- An HTML attachment was scrubbed... URL: From proski at gnu.org Wed Jul 31 16:44:26 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 31 Jul 2002 12:44:26 -0400 (EDT) Subject: Web editing with mc In-Reply-To: <20020731105942.4D0513CDF@xmxpita.excite.com> Message-ID: Hi, David! > Hmm! Maybe it needs some rewriting but HTML is getting quite complex. MC > should do a minimal highlighting just to help a bit. Style blocks in > HTML files may be highligted but there were problems with contexts > within other contexts. MC now does a _minimal_ highlighting. Enjoy. You are right, contexts cannot be nested. Also keywords at the end of the context extend the context, so there is no way to highlight ">" in closing tags. > Hmm!? Explain "maybe". Does is mean "Don't bother any more", "ASAP", "I > have to think about it", "I'm too busy and it's been queued"? No > complains. Just kidding a bit :) I mean, I don't apply any patches without testing. I was too busy to test "tidy" yesterday. -- Regards, Pavel Roskin