Re: msg-patch needs to be checked by experts
Vit R schrieb: II. Has it some meaning: maint/template.c:32: #include ... Yes. That file is a template that needs to be modified anyway. If you read the whole file, its intention should be clear to you. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: updated: [54d6ec8] replaced buggy concat_dir_and_file() by mhl_str_dir_plus_file()
Andrew Borodin schrieb:
On Sat, 31 Jan 2009 18:17:03 +0100 (CET) Enrico Weigelt, metux IT service
wrote:
+static inline char* mhl_str_dir_plus_file(const char* dirname, const char*
filename)
+{
+/* make sure we have valid strings */
+if (!dirname)
+dirname=;
Why is this necessary? The function is called dir_plus_file, so what's
the point of passing no directory at all?
+
+if (!filename)
+filename=;
Same for the filename. I'd rather add an assert(dirname != NULL) and
assert(filename != NULL).
+
+/* skip leading slashes on filename */
+while (*filename == '/')
+filename++;
If you follow the naming conventions of POSIX, a filename never contains
a slash.
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_169
+
+/* skip trailing slashes on dirname */
+int dnlen = strlen(dirname);
+while (dnlen (dirname[dnlen-1]=='/'))
+dnlen--;
Since dnlen is an int, not a boolean, you should treat it as such and
write (dnlen != 0).
+
+int fnlen = strlen(filename);
+char* buffer = mhl_mem_alloc_z(dnlen+fnlen+2); /* enough space for
dirname, /, filename, zero */
+char* ptr = buffer;
+
+memcpy(ptr, dirname, dnlen);
+ptr+=dnlen;
+*ptr = '/';
+ptr++;
The idiom *ptr++ is so common in C that every programmer should
understand it immediately. There's usually no gain in separating these
two actions.
+memcpy(ptr, filename, fnlen);
+ptr+=fnlen;
+*ptr = 0;
Please write '\0' to emphasize that you are working with characters, not
integers here. All the rest of the Midnight Commander codebase follows
the convention to write one space character around binary operators like
+=. It's good style to follow this convention.
+
+return buffer;
+}
+
#endif /* __MHL_STRING_H */
Oh, and by the way: Every identifier that starts with a double
underscore can result in undefined behavior.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: updated: [89d3cbd] Removed unneeded var to make build process a bit cleaner
Patrick Winnertz schrieb: @@ -61,7 +61,7 @@ static inline char* __mhl_str_concat_hlp(const char* base, ...) size_t totalsize = 0; // first pass: scan through the params and count string sizes -va_list par; +//va_list par; These comments are not valid in C90. And please don't use identifiers that start with a double underscore. They are reserved for the compiler. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: glib or not glib?
Andrew Borodin schrieb: On Wed, 7 Jan 2009 09:35:25 +0100 Enrico Weigelt wrote: * MC Ticket System tick...@midnight-commander.org schrieb: Why the _strcatdup() function is used instead of g_strconcat() one? First tiny step to get rid if glib. It's very strange. Do you think than mc must be free of glib? glib or not glib? I want to keep it. If we got rid of it, we would have to do everything glib does by hand. It comes very handy when dealing with data structures like lists, strings and so on. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
Enrico Weigelt schrieb: Hi folks, is it necessary to have the intl lib bundled into mc or could it be taken directly from the system ? (I admit, I don't know much about how it really works ;-o) I don't think it is necessary. There are many other projects who have dropped the internal intl/ directory. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15257] mc viewer enters a probably infinite cycle on some files with 8-bit characters
Update of bug #15257 (project mc): Status: Need Info = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?15257 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #23826] Segmentation fault when opening/browsing file
Update of bug #23826 (project mc): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #1: I cannot reproduce the bug with the current mc from CVS HEAD, nor with the upstream git archive that Debian uses. But when I apply the Debian patch, it crashes. You can tell the Debian people that it crashes because of: #0 0x7fa499e76f90 in strchr () from /lib/libc.so.6 #1 0x0045d51f in my_type_of (c=1048064) at edit.c:1821 #2 0x00460372 in edit_execute_cmd (edit=0x22997c0, command=value optimized out, char_for_insertion=value optimized out) at edit.c:1869 #3 0x004619fa in edit_execute_key_command (edit=0x22997c0, command=9, char_for_insertion=4294967295) at edit.c:2293 my_type_of(c) is called with c == 1046064 (a strange value). This is not zero (for which a check exists) but later used as an unsigned char in strchr(), where it is interpreted as zero. Because of that, the function my_type_of tries to read behind the option_chars_move_whole_word string, which leads to the segmentation fault. Please, if you use Debian, don't complain to the upstream authors. Complain to the Debian people. ___ Reply to this item at: http://savannah.gnu.org/bugs/?23826 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #24505] loading X11 library is broken
Update of bug #24505 (project mc): Status: Confirmed = Need Info ___ Follow-up Comment #2: Which version of mc are you using? The current version uses GModule for loading shared libraries, which should do the Right Thing automatically. At least I cannot find anything in the GModule documentation to explicitly load libX11.so.6. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24505 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #24505] loading X11 library is broken
Update of bug #24505 (project mc): Status: Need Info = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: Fixed in the current CVS version. If there is no libX11.so symlink, mc tries libX11.so.6 explicitly. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24505 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
Patrick Winnertz schrieb: So: At first the people who would like to work on mc should send a: I would like to do something. I'd like to. If there is some more action in mc development (like in 2005, when it was great fun), I'm definitely willing to invest some time into it. Maybe we even get all the different UTF-8 patches incorporated into mc. If that's possible without #ifdef's in each and every file, I'd like to work on it. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch] Invoking mcedit with filename:lineno
Hi,
many programs output warnings and errors in the format
filename:lineno[:]. The attached patch allows users to just copy and
paste these locations and invoke mcedit with them. For example:
$ mcedit main.c:2000
The patch maintains the usual behavior as much as possible. That is, the
new format is only used when the file main.c:2000 doesn't exist, but
main.c exists.
Opinions?
Roland
Index: doc/mcedit.1.in
===
RCS file: /cvsroot/mc/mc/doc/mcedit.1.in,v
retrieving revision 1.22
diff -u -p -r1.22 mcedit.1.in
--- doc/mcedit.1.in 24 Sep 2007 12:50:37 - 1.22
+++ doc/mcedit.1.in 9 Dec 2008 12:44:12 -
@@ -3,7 +3,10 @@
mcedit \- Internal file editor of GNU Midnight Commander.
.SH USAGE
.B mcedit
-[\-bcCdfhstVx?] [+number] file
+[\-bcCdfhstVx?] [+lineno] file
+.PP
+.B mcedit
+[\-bcCdfhstVx?] file:lineno[:]
.SH DESCRIPTION
.LP
mcedit is a link to
@@ -18,8 +21,8 @@ version of
\- standalone editor for X Window System.
.SH OPTIONS
.TP
-.I +number
-Go to the line specified by number (do not put a space between the
+.I +lineno
+Go to the line specified by number (do not put a space between the
.I +
sign and the number).
.TP
Index: src/main.c
===
RCS file: /cvsroot/mc/mc/src/main.c,v
retrieving revision 1.370
diff -u -p -r1.370 main.c
--- src/main.c 25 Sep 2007 15:33:37 - 1.370
+++ src/main.c 9 Dec 2008 12:44:12 -
@@ -2055,17 +2055,41 @@ handle_args (int argc, char *argv[])
if (!STRNCOMP (base, mce, 3) || !STRCOMP (base, vi)) {
edit_one_file = ;
if (tmp) {
- if (*tmp == '+' isdigit ((unsigned char) tmp[1])) {
- int start_line = atoi (tmp);
- if (start_line 0) {
- char *file = poptGetArg (ctx);
- if (file) {
- tmp = file;
- edit_one_file_start_line = start_line;
+ /*
+ * Check for filename:lineno, followed by an optional colon.
+ * This format is used by many programs (especially compilers)
+ * in error messages and warnings. It is supported so that
+ * users can quickly copy and paste file locations.
+ */
+ char *end = tmp + strlen (tmp), *p = end;
+ if (p tmp p[-1] == ':')
+ p--;
+ while (p tmp isdigit ((unsigned char) p[-1]))
+ p--;
+ if (tmp p p end p[-1] == ':') {
+ struct stat st;
+ gchar *fname = g_strndup (tmp, p - 1 - tmp);
+ if (mc_stat (tmp, st) == -1 mc_stat (fname, st) != -1) {
+ edit_one_file = fname;
+ edit_one_file_start_line = atoi (p);
+ } else {
+ g_free (fname);
+ goto try_plus_filename;
+ }
+ } else {
+ try_plus_filename:
+ if (*tmp == '+' isdigit ((unsigned char) tmp[1])) {
+ int start_line = atoi (tmp);
+ if (start_line 0) {
+ char *file = poptGetArg (ctx);
+ if (file) {
+ tmp = file;
+ edit_one_file_start_line = start_line;
+ }
}
}
+ edit_one_file = g_strdup (tmp);
}
- edit_one_file = g_strdup (tmp);
}
} else if (!STRNCOMP (base, mcv, 3) || !STRCOMP (base, view)) {
if (tmp)
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #24986] crash at startup because of using uninitialized variable
Update of bug #24986 (project mc): Severity: 3 - Normal = 4 - Important Open/Closed:Open = Accepted for 4.6.x ___ Reply to this item at: http://savannah.gnu.org/bugs/?24986 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Small bug in Version 4.6.1 wrapper scripts
Lawrence Cahoon schrieb: Hi: I found (and fixed, I think) a small bug in the mc-wrapper.sh file. As delivered, the 6th line of the script is: MC_PWD=`cat $MC_PWD_FILE` but I think it should be: MC_PWD=cat `$MC_PWD_FILE` I don't think you tested exactly this change successfully. The real fix is MC_PWD=`cat $MC_PWD_FILE` You can leave out the outer double quotes in a variable assignment (at least in sh; I don't know csh). Your suggestion of enclosing only the MC_PWD_FILE variable in backticks is wrong, since that variable contains a file name, and that file isn't executable. In the current mc's source, it has already been fixed. Thank you anyway for mentioning it. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #24594] Wrong sort in case-insensitive sort mode
Update of bug #24594 (project mc): Status:None = Invalid Assigned to:None = rillig Open/Closed:Open = Closed ___ Follow-up Comment #1: It's not mc's fault. The Midnight Commander is using the standard sorting of the currently selected language settings. Please try the following: $ env LC_COLLATE=C mc and if that doesn't work $ env LC_ALL=C mc and if it still doesn't work, come back. In that case, I'm sorry for having closed this bug report too fast. :) Roland ___ Reply to this item at: http://savannah.gnu.org/bugs/?24594 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #24505] loading X11 library is broken
Update of bug #24505 (project mc): Status:None = Confirmed Assigned to:None = rillig Operating System: GNU/Linux = All ___ Follow-up Comment #1: Thanks for catching this. I'll look into it. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24505 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #24038] slow starting of mc
Ies Nijman schrieb: Follow-up Comment #3, bug #24038 (project mc): Previous results were from MC 4.6.1 (fast starting). Next slow results from MC 4.6.2 and a strace file. Can you please include the relative timestamps in the strace file? The option is -t. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc-Bug?
7007h pooh schrieb: Hi, Let's make it short - my english isn't best ;) When connected to my ftp-server trough mc everything is all right, thanks for this! Now trying to copy something and the server timed-out (After few minutes) I get a segmentation fault - not what I want... You're right, every segmentation fault is a bug. Since you can reproduce this bug, please run gdb mc, make it crash, and then type backtrace at the GDB prompt, and send us the text that is printed there. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #22179] Inconsistent (and confusing) Tab behaviour
Update of bug #22179 (project mc): Status:None = Invalid Open/Closed:Open = Closed Operating System: GNU/Linux = All ___ Follow-up Comment #1: The behavior that you describe is exactly what is intended by the magic space feature. If you don't like it, you can switch it off by unchecking [x] fake half tabs in the editor configuration. Roland ___ Reply to this item at: http://savannah.gnu.org/bugs/?22179 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: problems with compiling mc
pavol pavelka wrote: hello, i would like to ask you if it is possible to compile mc under winXP and if so, what I have to do? I was trying to compile using Makefile.MIN in pc directory, but witha any success. I get used for mc in Linux and now I have to use Windows in my job and I really missing mc there. I will appreciate any advice, but do not advice me to use something like Total Commander, because I don't like using this file manager. (Just curious:) What are the features that makes Midnight Commander better than other file managers for you? And since you already tried to compile it: what were the exact error messages? Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #21959] bug in MC beim Start verbindung ins Internet
Update of bug #21959 (project mc): Category:None = VFS Status:None = Fixed Assigned to:None = rillig Open/Closed:Open = Accepted for 4.6.x Operating System: GNU/Linux = All ___ Follow-up Comment #7: Tja, also wenn das Problem die Kommas in der smb.conf sind, hängt das wohl nicht mit dem Midnight Commander zusammen. Das Beispiel in der smb.conf(5) manpage kommt ja auch ohne die Kommas aus. Ich habe einen Absatz zu der Problematik in die FAQ geschrieben. Damit ist der Fall für mich erledigt. :) Roland ___ Reply to this item at: http://savannah.gnu.org/bugs/?21959 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #21959] bug in MC beim Start verbindung ins Internet
Follow-up Comment #1, bug #21959 (project mc): Es könnte daran liegen, dass in der Samba-Konfigurationsdatei (/etc/smb.conf) in der Zeile interfaces = Netzwerk-Interfaces (z. B. eth0) statt IP-Adressen angegeben sind. Früher waren nur IP-Adressen erlaubt, mittlerweile auch Netzwerk-Interfaces. Der Midnight Commander benutzt ziemlich alten Samba-Quellcode, der nur IP-Adressen (bzw. Rechnernamen) versteht. Deshalb interpretiert er eth0 als Rechnername und versucht daraus eine IP-Adresse zu machen. Um das Problem zu beseitigen, gibt es zwei Möglichkeiten, die beide nur vom root-Benutzer erledigt werden können: 1. Die folgende Zeile in /etc/hosts eintragen: 127.0.0.1 eth0 # (ungetestet; falls es nicht geht, die IP-Adresse # von eth0; siehe ifconfig eth0) 2. In der Datei /etc/smb.conf die Interfaces-Zeile ändern und IP-Adressen statt Netzwerk-Interfaces eintragen. == Weitere Quellen == http://mail.gnome.org/archives/mc/2006-May/thread.html#5 ___ Reply to this item at: http://savannah.gnu.org/bugs/?21959 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Switching the internal editor between byte and UTF-8 mode
Hi, in recent discussions, there has often been the question whether the editor should be converted to UTF-8, and indeed, many Linux distributions have chosen to patch mc so that it does. I would at least like to keep the possibility of editing plain binary files, so I suggest to add a new option to the editor configuration where you can swap between byte-mode and UTF-8 mode. I currently don't have time to implement it, it's just that it would be nice to have. :) Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !
Additional Item Attachment, bug #3836 (project mc): File name: widget.c.patch Size:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?3836 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18191] mc crashes with segmentation violation when viewing /proc/registers
Follow-up Comment #1, bug #18191 (project mc): Note: this is fixed in the CVS version of mc, in which the viewer has been rewritten in large parts. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18191 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18121] calculation of major and minor device numbers is not portable
Update of bug #18121 (project mc): Status:None = Fixed Assigned to:None = rillig Open/Closed:Open = Closed ___ Follow-up Comment #1: This patch does not apply to the CVS version of mc. The major/minor definition is now handled in src/unixcompat.h, and I think your Interix case is well handled. Please try the current CVS version of mc. Note: There are currently no plans to apply patches to the mc-4.6.1 release. Development only takes place in the CVS version, and will be released some time in the future. Roland ___ Reply to this item at: http://savannah.gnu.org/bugs/?18121 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Slower viewer [was Re: Shall we have a release?]
Leonard den Ottolander wrote: Hi Roland, list, On Fri, 2006-08-04 at 06:35 +0200, Roland Illig wrote: You should try mc-4.6.1 then. It gets you to the end immediately. Note that we had a long time where mc-4.6.1 had already been branched, but I had rewritten the viewer in -HEAD. Slight mistake on my behalf. Although the tested rpm was older than 4.6.1 it was a HEAD tarball. Indeed a plain 4.6.1 jumps to the end of the file instantly. Still you brought down the line cache load time from 60 to 4 seconds. Less takes about 3 seconds to get to the end of the same file, which is a little more than the time the old viewer takes to go to a line number (F5) around the bottom of the file. Once the file has been read in the new viewer goto works instantly. Note that jumping back and forth to a line at the beginning and the end is actually faster in the new viewer. Jumping back from a far line to a close line in the old viewer is still instantaneous but jumping back to the far line actually takes 2 1/2 seconds again! I also have the impression the goto dialog is more sluggish in the old version. All in all only the initial End seems to have regressed. For the rest the new viewer actually behaves better than the one in 4.6.1. Once again, is this something we should suspend a release over? No, I don't think so. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Shall we have a release?
Leonard den Ottolander wrote:
Hi all,
It would be nice if we could have a new release (4.6.2) in a few weeks.
Although nothing spectacular has changed there have been some
improvements in the last 12 months.
If we agree on a release date I'm prepared to write down a list of
changes.
Please tell us of any urgent issues that need to be fixed before a
release.
The editor currently does not notice when a file is modified outside of
its control. This has often lead to overwriting files when I couldn't
remember which of my 20+ editor sessions was the one I have edited last.
The patch fixes that.
Roland
Index: editcmd.c
===
RCS file: /cvsroot/mc/mc/edit/editcmd.c,v
retrieving revision 1.151
diff -u -p -r1.151 editcmd.c
--- editcmd.c 17 Mar 2006 15:41:21 - 1.151
+++ editcmd.c 27 Jul 2006 09:57:18 -
@@ -276,6 +276,17 @@ edit_save_file (WEdit *edit, const char
return -1;
}
}
+
+ /* Prevent overwriting changes from other editor sessions. */
+ if (rv == 0 edit-stat1.st_mtime != 0 edit-stat1.st_mtime !=
sb.st_mtime) {
+ rv = edit_query_dialog2 (
+ _(Warning),
+ _(The file has been modified in the meantime. Save anyway?),
+ _(Yes),
+ _(Cancel));
+ if (rv != 0)
+ return -1;
+ }
}
if (this_save_mode != EDIT_QUICK_SAVE) {
@@ -381,6 +392,10 @@ edit_save_file (WEdit *edit, const char
}
if (mc_close (fd))
goto error_save;
+
+ /* Update the file information, especially the mtime. */
+ if (mc_stat (savename, edit-stat1) == -1)
+ goto error_save;
}
if (filelen != edit-last_byte)
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Shall we have a release?
Leonard den Ottolander wrote: Hi all, It would be nice if we could have a new release (4.6.2) in a few weeks. Although nothing spectacular has changed there have been some improvements in the last 12 months. If we agree on a release date I'm prepared to write down a list of changes. Please tell us of any urgent issues that need to be fixed before a release. The file viewer has become much slower for large files, which annoys some users. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Quoting of variables in fsusage.m4 and ls-mntd-fs.m4
Pavel Tsekov wrote: On Mon, 29 May 2006, Roland Illig wrote: Roland Illig wrote: The quoting hid one bug that appeared due to one variable being used, which had never been defined before. I think it has been fixed upstream. It has, and I updated our version of ls-mntd-fs.m4 to the one of coreutils. I also documented that in the ChangeLog. Sorry that it took so long. What do you think about my suggestion to move your changes in configure.ac to acinclude.m4 ? As a new macro? I don't think it's necessary, because I have added only a few lines, which would blow up the size of the configure script unnecessarily. But if you have some better reasons, please tell me. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Quoting of variables in fsusage.m4 and ls-mntd-fs.m4
Roland Illig wrote: The quoting hid one bug that appeared due to one variable being used, which had never been defined before. I think it has been fixed upstream. It has, and I updated our version of ls-mntd-fs.m4 to the one of coreutils. I also documented that in the ChangeLog. Sorry that it took so long. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] Fix progress reporting for file move
Hampa Hug wrote:
Hello
If a file is moved by copy/remove the progress bar is advanced twice. On
the other hand, if a file is moved by renaming the progress bar is never
updated. The attached patch fixes this.
Thanks for identifying and fixing this long-known bug. Before committing
the patch, I have one question left.
diff -ur mc-cvs/src/file.c mc-dev/src/file.c
--- mc-cvs/src/file.c 2006-04-25 05:05:17.0 +0200
+++ mc-dev/src/file.c 2006-05-03 07:09:36.0 +0200
@@ -1022,6 +1022,7 @@
{
struct stat src_stats, dst_stats;
int return_status = FILE_CONT;
+int copy = 0;
This variable looks like it should be of type gboolean. I also find its
name too generic; maybe copy_done would be more appropriate?
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16452] mcedit forgets POSIX newline at end of file
Follow-up Comment #4, bug #16452 (project mc):
mcedit is currently suitable for editing binary files, too. I wouldn't like
to give up this feature. So we had to do something like:
if (the current file looks like a text file) {
if (edit-size 0 get_byte(edit-size) != '\n') {
if (inputbox(This file does not end with a newline.
Shall we add it?, YES|NO|CANCEL) == YES) {
edit_insert_byte(edit-size, '\n');
}
}
}
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=16452
___
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15749] strange behavior with viewing files 2Gb
Update of bug #15749 (project mc): Status:None = Need Info Assigned to:None = rillig ___ Follow-up Comment #1: It's true that the viewer takes a long time to scroll at the end of a large file. Did I understand you correctly that scrolling to the end of a file 2 GB is momentarily, but it takes long only for files 2 GB? I would have expected it the other way round, so that files 2 GB take a long time and files 2 GB are quick (which might indicate a bug in the code). There is currently no way to avoid the waiting. It is used for line number generation, and perhaps that calculation could be delayed a bit or be done in the background. This would complicate the code, as the current commands for one line up, one line down, and so depend on the line numbers to be there. But it is certainly possible. Roland ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15749 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: ``ctime''
Pavel Tsekov wrote: On Fri, 10 Feb 2006, Pavel Tsekov wrote: We stumbled over this on IRC as a guy asked how to set the ``creation time'' for a file, and after a while we found out he's using MC. MC talks of ctime as it was creation time. Is there a specific reason for that? I searched manpage and sourcecode. No hints. Where did you get that source code ? There is no reference to creation time in the current source code. You are right though that in the manpage says creation time. Indeed there is one: 2005-09-05 Roland Illig [EMAIL PROTECTED] * info.c: [...] st_ctime is not the creation time, but the status change time. And, Pavel, I think mc-devel was the appropriate mailing list, since this could (and maybe should) be seen as a bug report. Anyway, the code has been fixed since a long time, and the man page since a few minutes. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: AMC patches ported to mc-2006-02-03-13.tar.gz
Pavel Tsekov wrote: On Mon, 6 Feb 2006, Arpi wrote: On Sun, 5 Feb 2006, Arpi wrote: select_dirs.patch In select/unselect files dialog: let mask/ select directories only, and /mask select dirs+files This doesn't seem very intuitive. Why? /mask things in the current (/) directory mask/ or /mask/ only directories (path has '/' ending) here maskfiles (old behaviour) To me it is not obvious. When I see `/' I think root directory. Anyway, this is just me. What worries me most is the fact that this patch changes the old behaviour. I'd like to hear what other people think of it. Selecting directories with a mask looks useful to me, but the leading slash indeed looks odd. Concerning prior art: The shell expands */ to all directories in the current directory, and * to all files and directories. Here, the problem is that mc's behavior already differs from sh's. Otherwise I'd say we just imitate the shell. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #14155] 4.6.1: mouse wheel strangeness
Update of bug #14155 (project mc): Status: Fixed = Need Info Open/Closed: Closed = Open ___ Follow-up Comment #15: The second patch broke mouse handling on a number of terminal emulators for me. This is an overview of which terminals can handle which escape sequence. [?1000h [?1002h Terminal --- xx xterm x- rxvt x- aterm xx pterm (PuTTY) -- Eterm For me, the patch broke more than it helped. Please add your experiences, so we can discuss on how to solve this problem. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch] new pty allocation strategy for BSD
Hi,
subshell.c currently contains hard-coded values for the available pty
names. These names do not match with the ptys that can be found on
actual systems. NetBSD 3.0 has ptyp[0-9A-Za-z], as well as
pty[qrs][0-9A-Za-z], so mc can only use 64 of the 100 available ptys.
There may be similar issues on other systems, I haven't checked.
The appended patch just scans through the /dev/ directory, looking for
anything that matches /^pty..$/.
Roland
Index: subshell.c
===
RCS file: /cvsroot/mc/mc/src/subshell.c,v
retrieving revision 1.90
diff -u -p -r1.90 subshell.c
--- subshell.c 23 Jan 2006 18:55:36 - 1.90
+++ subshell.c 4 Feb 2006 11:57:08 -
@@ -39,6 +39,10 @@
#endif
#include unistd.h
+#ifndef HAVE_GRANTPT
+# include dirent.h
+#endif
+
#ifdef HAVE_STROPTS_H
# include stropts.h /* For I_PUSH */
#endif /* HAVE_STROPTS_H */
@@ -67,7 +71,7 @@ static char tcsh_fifo[128];
static void init_raw_mode (void);
static int feed_subshell (int how, int fail_on_error);
static void synchronize (void);
-static int pty_open_master (char *pty_name);
+static int pty_open_master (char *pty_name, size_t pty_name_size);
static int pty_open_slave (const char *pty_name);
static int resize_tty (int fd);
@@ -406,7 +410,7 @@ init_subshell (void)
/* FIXME: We may need to open a fresh pty each time on SVR4 */
- subshell_pty = pty_open_master (pty_name);
+ subshell_pty = pty_open_master (pty_name, sizeof(pty_name));
if (subshell_pty == -1) {
fprintf (stderr, Cannot open master side of pty: %s\r\n,
unix_error_string (errno));
@@ -1071,7 +1075,7 @@ static void synchronize (void)
/* System V version of pty_open_master */
-static int pty_open_master (char *pty_name)
+static int pty_open_master (char *pty_name, size_t pty_name_size)
{
char *slave_name;
int pty_master;
@@ -1082,10 +1086,10 @@ static int pty_open_master (char *pty_na
/* getpt () is a GNU extension (glibc 2.1.x) */
pty_master = getpt ();
#elif IS_AIX
-strcpy (pty_name, /dev/ptc);
+g_strlcpy (pty_name, /dev/ptc, pty_name_size);
pty_master = open (pty_name, O_RDWR);
#else
-strcpy (pty_name, /dev/ptmx);
+g_strlcpy (pty_name, /dev/ptmx, pty_name_size);
pty_master = open (pty_name, O_RDWR);
#endif
@@ -1099,7 +1103,7 @@ static int pty_open_master (char *pty_na
close (pty_master);
return -1;
}
-strcpy (pty_name, slave_name);
+g_strlcpy (pty_name, slave_name, pty_name_size);
return pty_master;
}
@@ -1151,36 +1155,45 @@ pty_open_slave (const char *pty_name)
#else /* !HAVE_GRANTPT */
/* BSD version of pty_open_master */
-static int pty_open_master (char *pty_name)
+static int pty_open_master (char *pty_name, size_t pty_name_size)
{
int pty_master;
-const char *ptr1, *ptr2;
+DIR *dir;
+struct dirent *ent;
+const char *p;
-strcpy (pty_name, /dev/ptyXX);
-for (ptr1 = pqrstuvwxyzPQRST; *ptr1; ++ptr1)
-{
- pty_name [8] = *ptr1;
- for (ptr2 = 0123456789abcdef; *ptr2; ++ptr2)
- {
- pty_name [9] = *ptr2;
+pty_master = -1;
- /* Try to open master */
- if ((pty_master = open (pty_name, O_RDWR)) == -1) {
- if (errno == ENOENT) /* Different from EIO */
- return -1;/* Out of pty devices */
- else
- continue; /* Try next pty device */
- }
- pty_name [5] = 't'; /* Change pty to tty */
- if (access (pty_name, 6)){
- close (pty_master);
- pty_name [5] = 'p';
- continue;
- }
- return pty_master;
- }
+if ((dir = opendir (/dev)) == NULL)
+ return -1;
+
+while ((ent = readdir (dir)) != NULL) {
+
+ /* d_name =~ qr^pty..$ */
+ p = ent-d_name;
+ if (!(*p++ == 'p' *p++ == 't' *p++ == 'y'
+ *p++ != '\0' *p++ != '\0' *p++ == '\0')) {
+ continue;
+ }
+
+ if (g_strlcpy (pty_name, /dev/, pty_name_size) = pty_name_size ||
+ g_strlcat (pty_name, ent-d_name, pty_name_size) = pty_name_size)
+ break; /* pty_name too short */
+
+ /* Try to open master */
+ if ((pty_master = open (pty_name, O_RDWR)) == -1)
+ continue;
+
+ pty_name [5] = 't'; /* Change /dev/pty to /dev/tty */
+ if (access (pty_name, W_OK | R_OK) == 0)
+ break; /* We've found a terminal */
+
+ close (pty_master);
+ pty_master = -1;
}
-return -1; /* Ran out of pty devices */
+
+closedir (dir);
+return pty_master;
}
/* BSD version of pty_open_slave */
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #14155] 4.6.1: mouse wheel strangeness
anonymous wrote: Follow-up Comment #7, bug #14155 (project mc): hey everyone. ok so this problem had been bugging me too. and i see the patch fixed it and for that I am very grateful. but now it appears something else has broke, the situation is this; i use Eterm for my terminal. I noticed that the function keys and the mouse did not work with mc from Eterm, but they worked fine with xterm. eventually how I got around this was by symlinking my Eterm binary to a file called xterm, and then setting my enviroment variable TERM to xterm. I have just committed a patch that adds Eterm to the list of terminals that understand mouse sequences. It works for me now. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: current CVS mc isn't compilable
Pavel Tsekov wrote: Fixed. Oops and thanks. :) Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Crash on hexediting empty file
Pavel Tsekov wrote:
Index: src/view.c
===
RCS file: /cvsroot/mc/mc/src/view.c,v
retrieving revision 1.353
diff -u -p -r1.353 view.c
--- src/view.c 1 Feb 2006 15:59:21 - 1.353
+++ src/view.c 2 Feb 2006 08:49:45 -
@@ -2901,7 +2901,7 @@ view_labels (WView *view)
my_define (h, 2, Q_(ButtonBar|Edit),
view_toggle_hexedit_mode_cmd, view);
} else {
- my_define (h, 2, , NULL, view);
+ buttonbar_clear_label (h, 2);
Looks great. Please commit.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #11951] [RFE] Show size of all files in directory
Update of bug #11951 (project mc): Category: Editor = Core Status:None = Fixed Assigned to:None = rillig Open/Closed:Open = Closed ___ Follow-up Comment #5: This feature exists in the current development version. Press C-space. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=11951 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #10557] [PATCH] makes brief listing mode selectable with ALT+T
Update of bug #10557 (project mc): Status:None = Fixed Assigned to:None = rillig Open/Closed:Open = Closed ___ Follow-up Comment #1: Fixed in the current development version. Thanks for the patch. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=10557 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15461] vfs/extf for rpm/trpm query obsolete rpm tags
Update of bug #15461 (project mc): Category:None = VFS ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15461 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15057] Feature request, please add support for dar archives
Update of bug #15057 (project mc): Category:None = VFS ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15057 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #4741] Syntax Support for config files (conf,ini,cfg,...)
Update of patch #4741 (project mc): Status:None = Need Info Assigned to:None = rillig ___ Follow-up Comment #1: This patch doesn't use the coloring theme that has been established by the other syntax files, in which green is used for string literals, and brown for comments. Can you please add some comments to the conf.syntax file, explaining which types of configuration files need the ;; highlighted in red? Currently it looks like if you have made the assumption that all config files look like shell scripts. That's far too specialized. Roland ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4741 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Add a command line switch to disable X11 connection
Pavel Tsekov wrote: The patch is pretty simple. Comments, etc are much appreciated. You forgot to change the documentation in doc/mc.1.in. Besides that, it looks fine. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Add a command line switch to disable X11 connection
Pavel Tsekov wrote: On Sat, 28 Jan 2006, Roland Illig wrote: Pavel Tsekov wrote: The patch is pretty simple. Comments, etc are much appreciated. You forgot to change the documentation in doc/mc.1.in. Besides that, it looks fine. Are you sure that I didn't change it ? From what I can read in your patch, yes. If you changed it locally, please include it in the patch next time. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #4327] ftpfs confused by certain directory names
Leonard den Ottolander wrote: Follow-up Comment #5, bug #4327 (project mc): The third paragraph in comment #4 is a incorrect combination of 2 thoughts. What I meant to say is: 1) We can't determinate whether the date string is 3 or 4 fields long if the file name contains spaces so we need to fix our input vfs_parse_filedate(). A different function is needed if we know the date field has 4 elements. 2) If we want to be able to parse uids and gids with spaces in them we need to use a non-sequential parsing algorithm (look for date field first and work forward and backward from there). Currently uids and gids are supposed to be numerical so we don't have such a problem. Just another idea: We could use the NLST command to only list the names of the files and later check for them in the LIST command. This would make it possible to deal with all but filenames containing \r\n. This task is non-trivial to get optimal, but we could at least try ... Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #2796] cons.saver in wrong directory
Update of bug #2796 (project mc): Status:None = Fixed Assigned to:None = rillig Open/Closed:Open = Closed ___ Follow-up Comment #6: Fixed in the current development version. Thanks for the bug report. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=2796 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #4327] ftpfs confused by certain directory names
Follow-up Comment #3, bug #4327 (project mc): The current development version has the valid range of years restricted to 1970 .. 2015. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=4327 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #4835] MC misinterprets input
Update of bug #4835 (project mc): Status: Need Info = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #2: Feedback timeout. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=4835 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15257] mc viewer enters a probably infinite cycle on some files with 8-bit characters
Update of bug #15257 (project mc): Status:None = Need Info Assigned to:None = rillig ___ Follow-up Comment #1: This is most likely because your TERM environment variable is set to some terminal that mc does not know. For some terminals, like xterm*, rxvt*, and some others mc automatically filters out this kind of characters. Which value does your TERM environment variable have? Does the problem disappear when you call mc with the -x option? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15257 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: accels busted
Pavel Tsekov wrote: It would be nice if Roland joined the discussion... Yes, he really should. After all, it's him who broke mc all the time. Who's going to ask him? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: accels busted
Oswald Buddenhagen wrote:
one of the recent commits broke the alt-letter from main menu
accelerators in mcedit.
a related thing that always annoyed me: once you are in the menu (after
f9), pressing just the unmodified letter should open the respective
submenu as well.
I had not checked the patch that introduced the user-defined key
bindings enough. To fix this issue, I suggest the appended patch to be
applied.
Roland
Index: editkeys.c
===
RCS file: /cvsroot/mc/mc/edit/editkeys.c,v
retrieving revision 1.18
diff -u -p -r1.18 editkeys.c
--- editkeys.c 10 Aug 2005 16:47:44 - 1.18
+++ editkeys.c 28 Jan 2006 01:22:14 -
@@ -262,23 +262,9 @@ edit_translate_key (WEdit *edit, long x_
continue;
if (key_map[i].key != 0) {
command = key_map[i].command;
- goto fin;
}
-/* Function still not found for this key, so try macros */
-/* This allows the same macro to be
- enabled by either eg ALT('f') or XCTRL('f') or XCTRL('a'), 'f' */
-
-if (x_key ALT (0)) { /* is an alt key ? */
- command = CK_Macro (x_key - ALT (0));
- goto fin;
-}
-if (x_key ' ') { /* is a ctrl key ? */
- command = CK_Macro (x_key);
- goto fin;
-}
fin:
-
*cmd = command;
*ch = char_for_insertion;
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [RFE][PATCH] Display free space on device in panels
Jindrich Novy wrote:
--- mc-4.6.1a/src/screen.c.showfree 2005-12-28 16:49:52.0 +0100
+++ mc-4.6.1a/src/screen.c2005-12-28 17:14:45.0 +0100
@@ -106,6 +107,12 @@ int filetype_mode = 1;
/* The hook list for the select file function */
Hook *select_file_hook = 0;
+/* Old current working directory for displaying free space */
+char *old_cwd = NULL;
+
+/* Used to figure out how many free space we have */
+struct my_statfs myfs_stats;
+
As these variables are not mentioned in any header file, they should be
static.
static cb_ret_t panel_callback (Widget *, widget_msg_t msg, int parm);
static int panel_event (Gpm_Event *event, void *);
static void paint_frame (WPanel *panel);
@@ -851,6 +858,41 @@ paint_dir (WPanel *panel)
standend ();
}
+
+static void
+show_free_space(WPanel *panel)
+{
+struct stat st;
+
+/* Don't try to stat non-local fs */
+if (strlen(panel-cwd) = 2 panel-cwd[0] == '/' panel-cwd[1] ==
'#')
+ return;
We have vfs_current_is_local() and vfs_file_is_local(), which should be
used instead of this hack.
+if (old_cwd == NULL || strcmp(old_cwd, panel-cwd)) {
Please always compare the result of strcmp() to an integer, in this case 0.
+ init_my_statfs();
+ if (old_cwd != NULL) g_free(old_cwd);
The if (...) is unnecessary.
+ old_cwd = g_strdup(panel-cwd);
+}
+
+my_statfs (myfs_stats, panel-cwd);
+st = panel-dir.list [panel-selected].st;
+
+if (myfs_stats.avail 0 || myfs_stats.total 0) {
+ char buffer1 [6], buffer2[6], *tmp;
+ size_trunc_len (buffer1, 5, myfs_stats.avail, 1);
+ size_trunc_len (buffer2, 5, myfs_stats.total, 1);
+ tmp = g_strdup_printf (_(%s (%d%%) of %s), buffer1, myfs_stats.total ?
Please compare myfs_stats.total to 0 instead of treating it like a
boolean variable.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Proper names
Pavel Roskin wrote: Hello! On Tue, 2005-12-20 at 20:45 +0100, Marcin Garski wrote: Hello, Here is the patch that changes names to it proper version, like Red Hat, GNOME, GTK+. I think it's wrong to fix ChangeLog files in such way. I understand fixing spacing or obvious typos, but rewriting history of the project to use official names of software - it just smells like 1984. What if GNOME is renamed to EMONG tomorrow? Would we rewrite the project history again? You're right for the ChangeLogs. They document the history of the project, including the developer's lack to spell out other project's names correctly. For those files of mc that are current, I suggest that we change the names appropriately. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] PHP syntax highlighting broken
Jindrich Novy wrote: Hello mc-devel, the php.syntax file is broken due to bad highlighting definition of LOG_LOCAL[0-7] symbols. To reproduce: F4 on any .php file. Results: Error in file /usr/share/mc//syntax/php.syntax on line 4367 and file is edited without any highlighting. Patch is attached. Committed, Thanks. I have removed the ChangeLog from the syntax file, and left only a list of authors. We don't really need _three_ different ChangeLogs. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] concat_dir_and_file() needs fixes
Jindrich Novy wrote:
--- mc-4.6.1a/src/util.c.jn 2005-12-02 11:08:26.0 +0100
+++ mc-4.6.1a/src/util.c2005-12-02 13:11:19.0 +0100
@@ -1515,9 +1515,16 @@
/* If filename is NULL, then we just append PATH_SEP to the dir */
char *
-concat_dir_and_file (const char *dir, const char *file)
+concat_dir_and_file (const char *dir, const char *filename)
{
int i = strlen (dir);
+const char *file = filename;
+
It's obvious that you used mcedit here. :) (Hint: trailing white-space.)
+/* Return filename when dir is empty */
+if (!i) return g_strdup (filename);
This looks almost good, except that i is not a boolean variable. You
should use if (i == 0) instead.
+
+if (file != NULL *file == PATH_SEP)
+ file++;
Maybe we should rather make sure that this function is never called with
non-empty dir and file starting with a slash. Otherwise we might
hide bugs. How often do you want to concatenate two absolute paths?
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Depency on ld-linux.so.2(GLIBC_PRIVATE)
Leonard den Ottolander wrote: Hi Roland, On Tue, 2005-11-15 at 23:17 +0100, Roland Illig wrote: If you insist on this fix, please put the 0 at the beginning of the line. Otherwise it's likely to be missed. Please do :) -#if !defined(HAVE_ISSETUGID) ... +#if 0 /* was: !defined(HAVE_ISSETUGID) ... */ I think this is the best way to change it, since it cannot have problems with operator precedence (imagine #if foo || bar 0). Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Depency on ld-linux.so.2(GLIBC_PRIVATE)
Leonard den Ottolander wrote: AFAICT it's not unusual to fix such issues with a minimal diff. If you insist on this fix, please put the 0 at the beginning of the line. Otherwise it's likely to be missed. I could remove the entire block, but I might just wait for this to be fixed upstream. Do you really think they will fix it? Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcslang2
Pavel Tsekov wrote: Suddenly everyone on this list is only interested in sporting the right tone. Whatever the tone it cannot hide the fact that decisions are made from people that hardly have the skills to do so. Just to remind you: Leonard hasn't made a decision, but only a suggestion. There's a difference between them. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: new VFS directory listing parser
Leonard den Ottolander wrote: Hi Roland, On Tue, 2005-09-27 at 01:27 +0200, Roland Illig wrote: The current directory listing parser (for ftpfs and extfs) has problems with file names starting with white-space or a four-digit sequence. The latter is caused by the fact that different types of time format are accepted: Mon DD , Mon DD hh:mm, Mon DD hh:mm and Mon DD hh:mm . This makes it so the code doesn't know if it parsed the full date after having parsed the first 3 fields. If you've just dropped the assumption there are more than 3 fields and only accept Mon DD and Mon DD hh:mm as valid formats the existing code can quite easily be patched instead of doing a whole rewrite. See utilvfs.h around line 635 (This is a special case for ctime). Add a var got_time and stop parsing the date after either got_time or got_year. After I had rewritten vfs_parse_filetype and vfs_parse_fileperms (see utilvfs.c), I found the interface of these functions general enough so that it could be extended to the whole parsing of directory listings. I think one benefit of my code is that you can use all the parsing functions the same way. If you have used any of them, you know how to use all others. This has not been the case with the old code. My code makes it easy to add support for other file listing types, as every component of a listing line (filemode, size_or_rdev, filedate, uid, gid) has its own parsing function. If you look at the code of vfs_parse_unix_line(), this should become very clear. I also didn't like the function names. I expect that a function called is_year(...) does not modify its parameters (see the Java Coding Conventions). Most functions also used sscanf() for parsing, which is inappropriate, as sscanf(%d, 123XXX, n) will return 123, although 123X does not represent a number. And yes, I have dropped that assumption. I have started to collect example listing from some FTP servers, but they are still too few. I will also examine the Indy FTP code (see http://www.indyproject.org/), which has some more examples. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcslang2
Leonard den Ottolander wrote: Hi Pavel, On Tue, 2005-09-27 at 20:39 +0200, Pavel Tsekov wrote: Bootstrap the code and see the generated configure file. Similiar construct is used but in different context. I told you many times - you are too fast, too eager. I didn't say this patch was perfect yet. Looking for some feedback to improve it. Sorry for not posting the correct patch immediately. configure, make distcheck and a consequent build after configure --with-screen=mcslang2 is fine (assuming the correct patch is applied, which still awaits moderator approval, but you got it already). Please explain to me why the first use of #if SLANG_VERSION is invalid, but the second isn't. And what am I supposed to see in the configure script that needs correction? AC_DEFUN([MC_SLANG_PRIVATE], [ AC_CACHE_CHECK([if S-Lang exports private functions], [mc_cv_slang_private], [ ac_save_LIBS=$LIBS #if SLANG_VERSION 2 LIBS=$LIBS -lslang #else LIBS=$LIBS -lslang2 #endif As Pavel already said, you are writing shell programs here. So the #if, #else and #endif are actually comments. Your linker will most likely have -lslang -lslang2 somewhere in its command line. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Proposal for simplification
Pavel Roskin wrote: 3) Support only versions of gettext that have ngettext(), i.e. drop gettext 0.10.x. There had been the suggestion that we don't use internal gettext at all. This would simplify at least the ./autogen.sh and the configure script. It would also reduce the size of the tarball by about 80k. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcslang2
Pavel Tsekov wrote: [...] I told you many times - you are too fast, too eager. This is not the right tone for feedback. Leonard hasn't yet committed his change. If he had, this tone would be appropriate. Please choose your words to sound a little more polite. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: locale(1) and iso9660 extfs
q# wrote: -save_ctype=`locale | grep LC_CTYPE` +save_ctype=`locale 2/dev/null | grep LC_CTYPE` Committed. Thanks. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
new VFS directory listing parser
The current directory listing parser (for ftpfs and extfs) has problems with file names starting with white-space or a four-digit sequence. Today I have completely rewritten the parser code. The file vfsparse.h in the patch contains a lot of parsing functions that can be used not only in the vfs part, but also as stand-alone functions. They contain a simple-to-use, common interface that makes it easy to combine the functions to parse bigger blocks (see vfs_parse_unix_line for an example). I have tested the patched code on some servers, and it worked fine. I haven't yet tested the MS-DOS-style listing code, as I haven't found any FTP server providing that type of listing. I also haven't found any FTP server that doesn't include the `group' column in its output. If you know of any weird FTP servers that are not handled by this code, please tell me. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: new VFS directory listing parser
Forgot the patch. ;) Roland ftpfs-listing.patch.gz Description: GNU Zip compressed data ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
AFK until Sep 21 2005
Hello mc developers, I will be mostly away from keyboard until Sep 21. In the first days, I will still have some access to read my mails. Have a nice time. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Little Translation HOWTO (was: Translators wanted)
Dear translators, I got some mails that we got some translators who haven't done any translation before. This mail contains some basic instructions that may help you translating. First, you need to download your translation file from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/po/. Open it with a text editor of your choice or a specialized translation editor (For example, I am using poedit for it.) Each translation item consists of: - a msgid, which is the English string that is to be translated. - a msgstr, which is the translated string. - a list of locations in the source code, where the translation is used. This can help you if you don't understand the msgid from simply reading it. - There is a special msgid at the top of each file, which contains information about the translation file. You should add your name and mail address in the Last-Translator field. The PO-Revision-Date field should contain the date when you finished the translation. You can ignore the Language-Team field, as that is not used by the Midnight Commander project. In most cases you fill in the translated msgstr any you're done. There are, however, some caveats that you should know. - Space characters are important. Many dialog texts or titles contain a leading and a trailing space. Generally you should leave them how they are, except if the version without spaces looks better. - Some strings contain magic sequences like %s, %d or even more complex ones like %-02d. These sequences are replaced later with other strings (%s) or numbers (%d). Please try to keep them ordered, that is: don't translate error in file %s, line %d with line %d of file %s contains an error. - Some strings start with ButtonBar:. These are the labels of the keybar that is shown at the bottom of the screen. The translated strings should not be longer than six characters, as only the first six characters are actually displayed. - Lines starting with # are comments. Lines starting with #~ are old translations which you can use as a guideline, but which are not needed anymore. When you think you're done with the translation, run the msgfmt(1) program like this: msgfmt -cv foo.po The -c option enables some warnings and the -v option prints out the statistics about the translation status. When there are no error messages or warnings left, you are finished. Now you can send your .po file to the mc-devel mailing list and wait for it to be committed to the mc source code. If there are any questions left, please ask. :) Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Translators wanted
Hi, some years ago, the Midnight Commander had been translated quite well into a whole bunch of languages other than English. Somehow, the translation process has stalled sadly. If you want to help us getting translations of the Midnight Commander, please write to the mc-devel@gnome.org mailing list. If you already know how to translate .po files, you can also download the current versions from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/po/. The current state of the translations is: language translated fuzzy untranslated --- az 869 6258 be 880 5455 bg 879 5753 ca 870 6257 cs 906 4241 da 870 6158 de 986 3 0 el 123 59 807 es 968 318 eu 871 6157 fi 327 89 573 fr 880 5752 hu 980 8 1 it 986 3 0 ja 870 6158 ko 893 4155 lt 942 1730 lv 866 6261 mn 905 4341 nl 928 2734 no 892 5047 pl 905 4242 pt 879 5753 pt_BR 835 8569 ro 906 4241 ru 941 1434 sk 906 4241 sl 906 4241 sr 920 3534 sv 906 4241 ta 137 32 820 tr 870 6158 uk 920 3534 vi 913 3838 wa 711 72 206 zh_CN 857 6072 zh_TW 861 7058 --- language translated fuzzy untranslated The strings in the untranslated column need to be translated from scratch. The strings in the fuzzy column had some similar strings, which can sometimes be translated using copy-and-paste. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bug in F2 menu.
Roland Illig wrote: ForestCreature wrote: try to gzip/bzip2 directory containig spaces fails. Example ~/my dir/ F2Enter Result my\ dir.tar.gz file contains no files. Thanks for the bug report. I can reproduce it and I'm working on it. It is fixed it the current development version of mc. To fix your current version, download the following file to ~/.mc/menu: http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/mc/mc/lib/mc.menu?rev=1.16 Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bug in F2 menu.
Pavel Tsekov wrote: Hello, On Tue, 6 Sep 2005, Leonard den Ottolander wrote: Hmmm, the Alt-space was more difficult than it seemed, so I have chosen to use a simple space, which is also much more convenient. The current development version contains the feature. You can download it from I am afraid such an option would interfere with a user trying to start a command with a space, which is f.e. useful when HISTCONTROL=ignorespace. Did you miss the fact that this is how Roland likes it ?! Indeed it is. And you can still start the command line with a space by pressing C-q space. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: tty.c
Pavel Tsekov wrote: Hello, On Thu, 1 Sep 2005, Roland Illig wrote: Another benefit of the wrapper is that it reduces the number of warnings for SLsmg_printf(), which is still declared as taking a char *, not a const char *, as first argument. Just build mc with gcc -Wwrite-string and see. Well, Roland, fixing warnings by doing stupid hacks is not the smartest thing to do. I don't think the hack is so stupid. We are using two-and-a-half different screen libraries which implement things differently. It's the cleanest solution to define an interface that describes a screen library providing all the features we actually use and wrap the functions of the real screen libraries. My goal is to completely rub out any #ifdef HAVE_SLANG outside of the tty, colors and slint modules. You could go to the Slang maintainer and ask him to change his code and you could eventually submit patches there and not to MC. You just want me out of the project, do you? ;) Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bug in F2 menu.
Leonard den Ottolander wrote: I am afraid such an option would interfere with a user trying to start a command with a space, which is f.e. useful when HISTCONTROL=ignorespace. I didn't know that this was a commonly used feature, but I've changed the key from a simple space to Ctrl-space, which had been unassociated before. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bug in F2 menu.
Leonard den Ottolander wrote: Hello Roland, On Tue, 2005-09-06 at 12:51 +0200, Roland Illig wrote: And you can still start the command line with a space by pressing C-q space. How convenient :-( . Get rid of this. I've already done that. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bug in F2 menu.
ForestCreature wrote: try to gzip/bzip2 directory containig spaces fails. Example ~/my dir/ F2Enter Result my\ dir.tar.gz file contains no files. Thanks for the bug report. I can reproduce it and I'm working on it. P.S.: And I would like to see a feature in future release : to see directory size on Spacebar keypress ( only if no symbols typed in cmd string ). Can it be also Alt-space instead of space? Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: tty.c
Pavel Tsekov wrote: Hello Roland, 2005-08-29 Roland Illig [EMAIL PROTECTED] * slint.c: The handling of user interrupts has been moved to ... * tty.c: ... this newly created file, which contains a simple, not yet complete interface to the terminal library. It should be used instead of depending directly on ncurses or SLang features. * tty.h: Added the new function prototypes from tty.c and some legacy definitions. Why ? Why another wrapper ? The stuff in myslang.h is supposed to emulate curses calls. Now you introduce another interface. Because this wrapper tells the reader which functions from the screen library we actually use. It is the set of features that both libraries provide. The new function names all start with tty_, which is a strong indication where to look for them when you need to know how they are implemented. Instead of the low-level function call sequence acs(), addch(), noacs(), you only need to call tty_print_alt_char(), which is much simpler. I don't want to depend directly on ncurses or slang, and I don't want one of them to look like the other one (like what myslang.h does now). I prefer having a small interface that provides all that we need in its own namespace. Then we have one point where we can see on which features of the screen library we depend and what the differences are. Another benefit of the wrapper is that it reduces the number of warnings for SLsmg_printf(), which is still declared as taking a char *, not a const char *, as first argument. Just build mc with gcc -Wwrite-string and see. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Long filenames
andrzej zaborowski wrote: There are only some minor issues about the new viewer: First, the navigation in hex mode is strange: when pressing the down arrow it will scroll only after the cursor gets to the bottom of the screen (like in editor) while up arrow scrolls immediately. I just fixed it. I had noted it myself some time ago, but never found the time to do the trivial patch. :( Also after using the search feature, the matching text is sometimes not highlighted correctly, I will further investigate in this. and the vertical bars (|) between each four columns sometimes change their colour depending on where the cursor is. I only could observe that the bars had been drawn differently when they were in the text found by the searching functions. I have completely rewritten the hex display function. The code had been a mess. Now the vertical bars always have the NORMAL_COLOR. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Long filenames
andrzej zaborowski wrote: Hello MC, I found that long filenames are not displayed correctly (or as I would expect them to be displayed) in the panels and in the line that shows the currently highlighted file below the panel. Normally when a given name is longer than the panel width it would show a number of characters from the beginning of the name, a tilde sign and a portion of the ending. However for names longer than 128 characters the part after tilde (~) is not taken from the end of the full name, instead the name is truncated to 128 chars. This would also affect displaying file lists in panels wider than 128 chars (which is not a real case ofcourse). Committed to HEAD. Thanks for the bug report. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] interruptible search in the viewer
Jindrich Makovicka wrote: The attached patch makes the search function interruptible by Ctrl-C. Committed. Thanks. I am not sure it it doesn't interfere with get_byte() stuff which can do some I/O, but block_search doesn't disable the interrupts during I/O either. I just fixed the case when using mc_read(). The other cases still need to be checked. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Jindrich Makovicka wrote: Hello, the new viewer has a problem with viewing files with DOS line separators, which manifests again in a lockup after pressing the End key. Then, it is impossible to move the view further, except by pressing the Home key. Can you provide a file where that lockup occurs? As always, I cannot reproduce the bug. But I have found another bug in the coordinate cache code. Opening the attached file and running mc_ccache_dump() results in an endless loop. I will first fix this one, perhaps it fixes your bug, too. Roland 1025 ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Pavel Tsekov wrote: Are you kidding ? Have you tried with the file I've sent you ? I've debugged the problem and there is no way that it wont happen. Are you using the correct MC binary ? I am using mc-HEAD with the exception of src/view.c, which I took from yesterday. I extracted the file from your mail, pressed Down until I reached the end of file, then pressed Up until I reached the beginning of the file. And I reached it. Or did I completely miss the point here? Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Pavel Tsekov wrote:
Another approach would be to simplify the following code from
view_move_up():
} else if (line = 1) {
view_coord_to_offset (view, linestart, line, 0);
view_offset_to_coord (view, line, col, linestart - 1);
/* if the only thing that would be displayed were a
* single newline character, advance to the previous
* part of the line. */
if (col 0 col % width == 0)
col -= width;
else
col -= col % width;
} else {
It is clear now that the assumption that `linestart - 1' is not always an
offset inside the text on the previous line.
EPARSE. Did you mean this:?
It is clear now that `linestart - 1' is not always an offset inside
the text on the previous line.
Why? If only because of the buggy coordinate cache, this does not count.
The bug is fixed.
Is it safe to assume that if `line' does exist `line - lines' would
also exist (of course if lines is not greater than line) ? If so why
don't we just do:
view_coord_to_offset (view, (view-dpy_topleft), line - lines, 0);
Because we are in text wrap mode. Internally the viewer stores the
unwrapped coordinates. When you want to go one line up, you have to
distinguish whether you are inside a long line or at the beginning of a
line. This is what the code does.
The code you suggest is used in the !hex_mode !text_wrap_mode case.
To my knowledge, the code cannot be made simpler. I could add some
comments to the code to make understanding it simpler. Shall I?
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Pavel Tsekov wrote: Hello, On Mon, 15 Aug 2005, Roland Illig wrote: Because we are in text wrap mode. Internally the viewer stores the unwrapped coordinates. When you want to go one line up, you have to distinguish whether you are inside a long line or at the beginning of a line. This is what the code does. Well, maybe the cache should be changed then. And btw this was idea that I have not investigated fully it just crossed my mind. But what is done now is clearly suboptimal. If the cache was changed, the code for the non-wrapping text mode would become more complicated, just as the text_wrap_mode code is now. I decided to store the unwrapped coordinates in the cache because the user might change the screen size, which would invalidate the whole cache if it contained the wrapped coordinates. The unwrapped coordinates also make displaying the current position very easy. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: view growbuf read until() suggestion
Roland Illig wrote: Index: view.c === RCS file: /cvsroot/mc/mc/src/view.c,v retrieving revision 1.313 diff -u -p -r1.313 view.c Committed. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH]: Minor cleanup in menubar_draw()
Pavel Tsekov wrote: Hello, hline() is used in so many places that if it had some bugs they would be noticed by now. I tested the patch and I haven't observed any visual problems. Committed, Thanks. As the code is from revision 1.1, we cannot expect anyone to tell us where the code originated from, right? Or perhaps Miguel, do you know how to find out details about code from revision 1.1? Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH]: Minor cleanup in menubar_draw()
Pavel Tsekov wrote: Hello, hline() is used in so many places that if it had some bugs they would be noticed by now. I tested the patch and I haven't observed any visual problems. There might be some weird behavior when the end of line is reached, but as the menubar is at the top of the screen, this shouldn't matter. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: shell scripting advise: Don't use backslashes inside backtick quotes
Oswald Buddenhagen wrote:
On Thu, Aug 04, 2005 at 07:31:42AM +0200, Oswald Buddenhagen wrote:
On Thu, Aug 04, 2005 at 01:19:50AM +0200, Roland Illig wrote:
quote() {
_sedexpr=s,',''',g
_quotestr=`echo x$1 | sed -e '1s,^x,,' -e ${_sedexpr}`
echo '${_quotestr}'
}
So if you ever use backticks, please don't use backslashes inside them.
yes, it's a well-known ;) fact that backticks have weird semantics when
it comes to about any other nested quoting.
really old shells will explode on your current version, too, but we
really needn't to consider those.
Why? Because of possible backslashes?
more importantly ... unless $1 is guaranteed not to contain backslashes,
things will go awfully wrong with some echo variants. safest is 'printf
%s $1' - supposedly all halfways modern systems have it ...
otherwise you could try to inject it by putting it into a sed i
statement, but i have no clue whether/how that works.
Thanks for that comment. I almost forgot. Shell programming is ugly. :(
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Edit selected/hilighted text
Michelle Konzack wrote: Hello, if I am in 'mcedit' and edit a text, I like to select a text and sned it via STDIN into a command and past the output (STDOUT) into the selection. Exactly I want to remplace the selection. How is this possibel ? It had been possible for a short while, somewhere in 2004. I had replaced some parts of the editor with code that did exactly what you want. But because some developers told me not to replace working code with your poorly tested new code, I removed it again. I would be happy to reintroduce my poorly tested code again, as it had worked great for me. :) Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Edit selected/hilighted text
Michelle Konzack wrote:
Am 2005-08-01 18:42:37, schrieb Roland Illig:
It had been possible for a short while, somewhere in 2004. I had
replaced some parts of the editor with code that did exactly what you
want. But because some developers told me not to replace working code
with your poorly tested new code, I removed it again.
Can your patch easyly applyed to the Debian-Version of mc ?
I like to see in in the editor.
To apply the patch to the Debian version you have to add the files
src/pipethrough.{c,h} from current CVS HEAD. Then it will work, too.
I would be happy to reintroduce my poorly tested code again, as it had
worked great for me. :)
Then we should encurage the mc-developers to check your patch.
And here it is, against HEAD.
Roland
Index: src/Makefile.am
===
RCS file: /cvsroot/mc/mc/src/Makefile.am,v
retrieving revision 1.44
diff -u -p -r1.44 Makefile.am
--- src/Makefile.am 31 Jul 2005 18:30:43 - 1.44
+++ src/Makefile.am 1 Aug 2005 19:33:57 -
@@ -60,7 +60,7 @@ SRCS =achown.c achown.h background.c ba
tree.c tree.h treestore.c treestore.h tty.h user.c user.h \
util.c util.h utilunix.c view.c view.h vfsdummy.h widget.c \
widget.h win.c win.h wtools.c wtools.h unixcompat.h \
- x11conn.h x11conn.c ecs.h ecs.c
+ x11conn.h x11conn.c ecs.h ecs.c pipethrough.h pipethrough.c
if CHARSET
mc_SOURCES = $(SRCS) $(CHARSET_SRC)
Index: edit/editcmd.c
===
RCS file: /cvsroot/mc/mc/edit/editcmd.c,v
retrieving revision 1.140
diff -u -p -r1.140 editcmd.c
--- edit/editcmd.c 24 Jul 2005 13:37:58 - 1.140
+++ edit/editcmd.c 1 Aug 2005 19:33:58 -
@@ -54,6 +54,7 @@
#include ../src/wtools.h /* message() */
#include ../src/charsets.h
#include ../src/selcodepage.h
+#include ../src/pipethrough.h
#define edit_get_load_file(f,h) input_expand_dialog (h, _( Enter file name:
), f)
#define edit_get_save_file(f,h) input_expand_dialog (h, _( Enter file name:
), f)
@@ -2424,36 +2425,72 @@ int edit_sort_cmd (WEdit * edit)
return 0;
}
-/*
- * Ask user for a command, execute it and paste its output back to the
- * editor.
- */
+/* Ask the user for a command, feed the currently selected block as its
+ * input and paste its output back to the editor. */
int
edit_ext_cmd (WEdit *edit)
{
-char *exp;
-int e;
-
-exp =
- input_dialog (_(Paste output of external command),
- _(Enter shell command(s):), NULL);
-
-if (!exp)
- return 1;
+const char *title_i18n = _( External Command );
+char *command = NULL;
+char *block = NULL;
+const char *error = NULL;
+long start_mark, end_mark;
+struct pipe_inbuffer inbuf = {NULL, 0};
+struct pipe_outbuffer outbuf = {NULL, 0};
+struct pipe_outbuffer errbuf = {NULL, 0};
+int block_len;
+int status;
+
+if (eval_marks (edit, start_mark, end_mark) == 0 /* OK */) {
+block = edit_get_block (edit, start_mark, end_mark, block_len);
+if (block == NULL) {
+ error = _( Could not get the current block. );
+goto cleanup;
+}
+}
+
+command = input_dialog (title_i18n, _( Enter a shell command: ), );
+if (command == NULL)
+goto cleanup;
+
+inbuf.data = block;
+inbuf.size = block_len;
+if (pipethrough(command, inbuf, outbuf, errbuf, status) == -1) {
+ error = get_sys_error (_( Error executing the shell command. ));
+ goto cleanup;
+}
+
+if (WIFEXITED(status)) {
+ if (WEXITSTATUS(status) != 0) {
+if (query_dialog(title_i18n, _( The command returned
unsuccessfully. Continue anyway? ),
+ D_ERROR, 2, _( Yes ), _( No )) != 0 /*
first button */)
+goto cleanup;
+ }
+} else {
+ error = _( The command died unexpectedly. );
+ goto cleanup;
+}
-e = system (catstrs (exp, , home_dir, TEMP_FILE, (char *) NULL));
-g_free (exp);
+if (edit_block_delete_cmd (edit) != 0)
+goto cleanup;
-if (e) {
- edit_error_dialog (_(External command),
- get_sys_error (_(Cannot execute command)));
- return -1;
+if (outbuf.data != NULL) {
+size_t i;
+for (i = 0; i outbuf.size; i++)
+edit_insert (edit, ((char *) outbuf.data)[i]);
}
-
edit-force |= REDRAW_COMPLETELY;
-edit_insert_file (edit, catstrs (home_dir, TEMP_FILE, (char *) NULL));
-return 0;
+cleanup:
+if (error != NULL) {
+edit_error_dialog (title_i18n, error);
+}
+
+pipe_outbuffer_finalize (outbuf);
+pipe_outbuffer_finalize (errbuf);
+g_free (block);
+g_free (command);
+return (error == NULL);
}
/* if block is 1, a block must be highlighted and the shell command
Re: Vietnamese UI Translation for Midnight Commander. Documentation?
Phan Vinh Thinh wrote: Hi, Few days ago, one guy on debian-russian mailing list gave me a Debian depository address (http://syavad.narod.ru/), which contains MC with UTF-8 support. It works, great! Thanks russian folks. And after that, I decided to translate this my favorite file manager into my native language - Vietnamese. Hello Phan, many thanks for your translation. I committed it today, and it will be included in any upcoming releases. Sorry for the long delay. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #13734] viewer should save position mode per file
/dev/rob0 wrote: Roland Illig wrote: Thus I have dozens of files listed with position 1;0 in filepos. Why are those saved at all? Would it be possible to save file position unless the position happens to be 1;0? Even #utar and other such temporary files have their position saved. I just fixed that. Excellent, thanks! Meaning just the position 1;0 issue, or that the VFS files are not saved, too? Only the position issue. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #13734] viewer should save position mode per file
/dev/rob0 wrote: Thus I have dozens of files listed with position 1;0 in filepos. Why are those saved at all? Would it be possible to save file position unless the position happens to be 1;0? Even #utar and other such temporary files have their position saved. I just fixed that. Is there a limit to the number of lines in filepos, like, say, .bash_history has? And yes, I did look in the man page before asking. :) Currently it is hard-coded to 1024. Do you want to have that configurable? Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Current translation status
Arpad Biro wrote: ta.po translated:0, fuzzy:0, untranslated:0, total:0 (BTW, the table also shows that ta.po is incorrect.) That's because you just examined the first line, which is an error message in the case of ta.po. If you had taken the last line instead, it would have worked. Or you just take my statistics.pl script from CVS HEAD. :) Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: getgrouplist(3) vs. getgroups(3)
Pavel Tsekov wrote: On Fri, 22 Jul 2005, Roland Illig wrote: I updated the patch. Seems nice. How about removing the configure bits related to getgrouplist() too ? Done in PRE. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: glibc and getgrouplist
Koblinger Egmont wrote: (strcmp(gnu_get_libc_version(), 2.3.3) 0) Why not? Note the comparison. Since 2.3.3, this should be definitely fixed. Please use strverscmp() or something similar. According to strcmp, 2.3.10 is smaller than 2.3.3. Hmmm, you're right. As we are sure to have a glibc, there's also a function strverscmp, which we can use. I had known this issue, but as glibc-2.2 only got upto 2.2.6, I thought it would suffice. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
getgrouplist(3) vs. getgroups(3)
Why do we use getgrouplist(3) at all? What we're interested in are the permissions of the current process, not what's in the system-wide database. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: getgrouplist segfault?
Pavel Tsekov wrote: Hello, On Fri, 22 Jul 2005, Roland Illig wrote: But another question arises: Do we want to keep this variable and the patch forever? Or will we remove it in one or two years? Does it make any difference ? Yes, it bloats the code. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: getgrouplist(3) vs. getgroups(3)
Roland Illig wrote:
Why do we use getgrouplist(3) at all? What we're interested in are the
permissions of the current process, not what's in the system-wide database.
After applying this patch, everything works as usual.
Why have we used a GTree for storing the group IDs of the process? In my
case, there are only three group IDs. Therefore the linear search is
much faster than a tree lookup.
$ id -G
100 0 5
$ id -Gn
users wheel operator
Roland
Index: main.c
===
RCS file: /cvsroot/mc/mc/src/main.c,v
retrieving revision 1.357
diff -u -p -d -r1.357 main.c
--- main.c 20 Jul 2005 20:30:03 - 1.357
+++ main.c 22 Jul 2005 08:17:12 -
@@ -2139,9 +2139,6 @@ main (int argc, char *argv[])
bindtextdomain (mc, LOCALEDIR);
textdomain (mc);
-/* Initialize list of all user group for timur_clr_mode */
-init_groups ();
-
/* Set up temporary directory */
mc_tmpdir ();
@@ -2244,9 +2241,6 @@ main (int argc, char *argv[])
/* Virtual File System shutdown */
vfs_shut ();
-
-/* Delete list of all user groups */
-destroy_groups ();
flush_extension_file (); /* does only free memory */
Index: utilunix.c
===
RCS file: /cvsroot/mc/mc/src/utilunix.c,v
retrieving revision 1.86
diff -u -p -d -r1.86 utilunix.c
--- utilunix.c 27 May 2005 03:35:15 - 1.86
+++ utilunix.c 22 Jul 2005 08:17:12 -
@@ -46,122 +46,30 @@
struct sigaction startup_handler;
-/* uid of the MC user */
-static uid_t current_user_uid = -1;
-/* List of the gids of the user */
-static GTree *current_user_gid = NULL;
-
-/* Helper function to compare 2 gids */
-static gint
-mc_gid_compare (gconstpointer v, gconstpointer v2)
-{
-return ((GPOINTER_TO_UINT(v) GPOINTER_TO_UINT(v2)) ? 1 :
- (GPOINTER_TO_UINT(v) GPOINTER_TO_UINT(v2)) ? -1 : 0);
-}
-
-/* Helper function to delete keys of the gids tree */
-static gint
-mc_gid_destroy (gpointer key, gpointer value, gpointer data)
-{
-(void) key;
-(void) data;
-g_free (value);
-
-return FALSE;
-}
-
-/* This function initialize global GTree with the gids of groups,
- to which user belongs. Tree also store corresponding string
- with the name of the group.
- FIXME: Do we need this names at all? If not, we can simplify
- initialization by eliminating g_strdup's.
-*/
-void init_groups (void)
-{
+/* Return the index of the permissions triplet */
+int
+get_user_permissions (struct stat *buf) {
+static gboolean initialized = FALSE;
+static gid_t groups[NGROUPS_MAX];
+static int n;
+static uid_t uid;
int i;
-struct passwd *pwd;
-struct group *grp;
-
-current_user_uid = getuid ();
-pwd = getpwuid (current_user_uid);
-g_return_if_fail (pwd != NULL);
-
-current_user_gid = g_tree_new (mc_gid_compare);
-/* Put user's primary group first. */
-if ((grp = getgrgid (pwd-pw_gid)) != NULL) {
- g_tree_insert (current_user_gid,
- GUINT_TO_POINTER ((int) grp-gr_gid),
- g_strdup (grp-gr_name));
+if (!initialized) {
+ uid = getuid();
+ n = getgroups(NGROUPS_MAX, groups);
+ initialized = TRUE;
}
-#ifdef HAVE_GETGROUPLIST
-{
- gid_t *groups = g_new (gid_t, 1);
- int ng = 1;
- gid_t *newgroups = NULL;
-
- if (getgrouplist (pwd-pw_name, pwd-pw_gid, groups, ng) == -1) {
- newgroups = g_new (gid_t, ng);
- if (newgroups != NULL) {
- g_free (groups);
- groups = newgroups;
- getgrouplist (pwd-pw_name, pwd-pw_gid, groups, ng);
- } else
- ng = 1;
- }
-
- for (i = 0; i ng; i++) {
- grp = getgrgid (groups[i]);
- if (grp != NULL
-!g_tree_lookup (current_user_gid,
- GUINT_TO_POINTER ((int) grp-gr_gid))) {
- g_tree_insert (current_user_gid,
- GUINT_TO_POINTER ((int) grp-gr_gid),
- g_strdup (grp-gr_name));
- }
- }
+if (buf-st_uid == uid || uid == 0)
+ return 0;
- g_free (groups);
-}
-#else
-setgrent ();
-while ((grp = getgrent ()) != NULL) {
- for (i = 0; grp-gr_mem[i]; i++) {
- if (!strcmp (pwd-pw_name, grp-gr_mem[i])
- !g_tree_lookup (current_user_gid,
- GUINT_TO_POINTER ((int) grp-gr_gid))) {
- g_tree_insert (current_user_gid,
- GUINT_TO_POINTER ((int) grp-gr_gid),
- g_strdup (grp-gr_name));
- break;
- }
- }
+for (i = 0; i n; i++) {
+ if (buf-st_gid == groups[i])
+ return 1;
}
-endgrent ();
-#endif
-}
-
-/* Return the index of the permissions triplet */
-int
