[bug #19245] [RFE] read-only or syntax highlight
Update of bug #19245 (project mc): Category:None = Viewer Severity: 3 - Normal = 1 - Wish Status:None = Duplicate Open/Closed:Open = Closed Summary: read-only or syntax highlight = [RFE] read-only or syntax highlight ___ Follow-up Comment #1: This request was already put in the bug database: Bug 13740. Closing as duplicate. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19245 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] subshell_name_quote() use printf instead of echo
Hello Pavel, On Thu, 2007-03-08 at 17:10 +0200, Pavel Tsekov wrote: On Thu, 1 Mar 2007, Pavel Tsekov wrote: This is patch which makes subshell_name_quote() use the printf utility instead of echo. Please, test it and let me know whether to commit it. Did anyone test this patch ? No, not actually tested, but the code looks alright. Only one remark: Strictly speaking the memcpy - strcpy changes are unrelated. But who cares :) ? Just commit the thing. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #13740] [RFE] syntax highlighting in viewer wanted
Update of bug #13740 (project mc): Severity: 3 - Normal = 1 - Wish Summary: syntax highlighting in viewer wanted = [RFE] syntax highlighting in viewer wanted ___ Reply to this item at: http://savannah.gnu.org/bugs/?13740 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Request for discussion - how to make MC unicode capable
Hello Pavel, On Sat, 2007-02-24 at 14:57 +0200, Pavel Tsekov wrote: I'd like to initiate a discussion on how to make MC unicode deal with multibyte character sets. Just a few thoughts: - Because multibyte is rather more memory hungry I think the user should still have the option to toggle the use of an 8bit path either in the interface or at compile time. This means where the UTF-8 patches replace paths we should preferably implement two paths. - I suppose a lot of the code of the UTF-8 patch can be reused, only we will need to add iconv() calls in the appropriate places. libiconv is already expected so not much trouble with the make files there. Iconv should only be used for the multibyte path, not the 8bit path. Using the multibyte path would still enable users to translate from one 8bit charset to another. - Unsupported character substitution character should be an ini option (and define some defaults for all/many character sets). (I'm not sure question mark is supported in all character sets.) - Users should be able to set character set per directory (mount). Of course there should be a system wide default taken from the environment (but also overridable). - Copy/move dialogs should have a toggle to iconv the file name or do a binary name copy. - Maybe copy/move dialogs should also have a toggle to iconv file content, which could be quite usable for text files. A warning dialog on every copy/move (that the user explicitly has to disable) might be a good addition then, to help uninformed users avoiding to screw up their data. These are the things I can come up with so far. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16029] MC doesn't open if network gateway inaccessible.
Follow-up Comment #8, bug #16029 (project mc): Should we close this as a duplicate of bug 5142 then? ___ Reply to this item at: http://savannah.gnu.org/bugs/?16029 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !
Update of bug #3836 (project mc): Status: Need Info = Works For Me Open/Closed:Open = Closed ___ Follow-up Comment #7: Issue mentioned comment #4 was caused by a history file being symlinked to /dev/null. Closing WORKSFORME. The use of lchmod() might be useful but cannot be implemented without proper configure tests for the existence of the function. ___ Reply to this item at: http://savannah.gnu.org/bugs/?3836 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !
Update of bug #3836 (project mc): Status:Works For Me = None Open/Closed: Closed = Open ___ Follow-up Comment #8: Based the closing of this bug on http://mail.gnome.org/archives/mc/2007-January/msg1.html , overseeing Egmont's remark. We could just as well have the general discussion whether to use lchmod() where appropriate (and available) here, so I'm reopening. I would suggest fixing the issue of chmodding targets of links throughout the code, not just for this specific case. ___ Reply to this item at: http://savannah.gnu.org/bugs/?3836 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] corrupted free inodes list
Hi Mikulas, On Wed, 2006-12-20 at 02:15 +0100, Mikulas Patocka wrote: --- maybe you could change double to long long but I'm not sure if it exists on all machines --- a configure test would probably be needed. Yes. Using floats for discrete counters is not such a good idea. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] mc crashes when temporary directory cannot be created
Hello Jindrich,
On Tue, 2006-11-28 at 13:21 +0100, Jindrich Novy wrote:
IMO only removal of the fallback will prevent
the infinite loop in any case as it shouldn't call mc_mkstemps() at all.
That cure seems worse than the disease. Isn't the real problem the fact
that mc_mkstemps() blindly concats tmpdir to the prefix instead of
testing if mc_tmpdir() succeeded? Why not abort mc_mkstemps() if
mc_tmpdir() returns /dev/null/?
What about the attached (untested) patch?
By the way, could you please add the -p option to your diffs?
Bye,
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
--- util.c.000 2005-11-10 21:50:22.0 +0100
+++ util.c 2006-11-29 20:56:21.0 +0100
@@ -1301,14 +1301,18 @@ mc_mkstemps (char **pname, const char *p
= abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789;
static unsigned long value;
struct timeval tv;
+char *tmpdir;
char *tmpbase;
char *tmpname;
char *XX;
int count;
if (strchr (prefix, PATH_SEP) == NULL) {
+ tmpdir = mc_tmpdir ();
+ if (strcmp (tmpdir, /dev/null/) == 0)
+ return -1;
/* Add prefix first to find the position of XX */
- tmpbase = concat_dir_and_file (mc_tmpdir (), prefix);
+ tmpbase = concat_dir_and_file (tmpdir, prefix);
} else {
tmpbase = g_strdup (prefix);
}
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Follow-up Comment #3, bug #18136 (project mc): Mehmet, instead of using the attached patch that breaks compatibility with bash 3.2 you might want to use the hack/patch that I posted to the mc-devel list in relation to this report. That patch is almost identical to this one, but by escaping numbers as well it remains compatible with bash 2.05b. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18136 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] FISH DoS when copying file with '`' in name to remote FS
Hi Jindrich, On Thu, 2006-11-09 at 13:44 +0100, Jindrich Novy wrote: I was unsuccessful to fix the script responsible for this bug by any quotation as backtick '`' did quite bad things so that bash was unable to parse it, quoted or not. Thanks for your explanation. Committed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17822] consecutive resize events not handled correctly
Follow-up Comment #7, bug #17822 (project mc): Committed. Quite an improvement in behaviour. Thank you. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17822 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] FISH DoS when copying file with '`' in name to remote FS
Hi Jindrich, On Wed, 2006-11-08 at 19:37 +0100, Jindrich Novy wrote: +file=/%s\n Why the substitution instead of just quoting the occurrences of %s? (unsigned long) s.st_size, name, -(unsigned long) s.st_size, quoted_name, -quoted_name, (unsigned long) s.st_size, quoted_name); +quoted_name, (unsigned long) s.st_size, +(unsigned long) s.st_size); And what is this doing? Is it in any way related to the quoting issue or does it fix something else? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17822] consecutive resize events not handled correctly
Follow-up Comment #6, bug #17822 (project mc): As I understand your patch/hack, eliminating the timeouts on a window resize event significantly reduces the chance mc is still waiting inside the get_event() loop when a new resize event occurs. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17822 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17822] consecutive resize events not handled correctly
Follow-up Comment #4, bug #17822 (project mc): Shall I commit this patch or should I wait for the piped version? ___ Reply to this item at: http://savannah.gnu.org/bugs/?17822 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] RPM vfs ignores conflicts
Hi Jindrich, On Wed, 2006-11-01 at 10:23 +0100, Jindrich Novy wrote: sure :) here we go with the patched trpm vfs as well. rpms fortunately doesn't need any changes. Yes, of course, trpm. Committed. Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18042] cannot specify port number in shell link
Hello Andrew, On Mon, 2006-10-30 at 12:04 +, Andrew V. Samoilov wrote: Follow-up Comment #3, bug #18042 (project mc): Do I understand correctly that a port number *can* be combined with C _or_ r? No. Look at utilvfs.c:vfs_split_url(). No one syntax change. Only undocumented behaviour changed. It is possible to use /#sh:[EMAIL PROTECTED]:6789 right now. Maybe we should introduce a syntax change, because at least the combination of a port number and C are very welcome. What about a solution whereby the user can add any of these options, in any particular order, all separated by colons? Would that be a lot of work to implement? And fish uses port1 as 'C' option and port2 as 'r'. Possible solution is to use 0x11 and 0x12 instead of 1 and 2. That would probably get rid of the need for an extra parameter to separate the port number from other options. I am not sure we can allow such redesign because of lack of manpower. Do I understand correctly that you are not willing to implement such a change? Can we at least agree on a new syntax if somebody (I?) would be willing to implement it? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hello Pavel, On Wed, 2006-11-01 at 13:27 +0200, Pavel Tsekov wrote: Yes, I read that comment. However I'm not prepared to start breaking the functionality of shells that I never use. This is a rather strange statement. As a developer you should try to go beyond your personal preferences. As I have limited time I will not be implementing a solution where we replace echo -e with printf. It's not that I don't prefer such a solution, it's just that I will not be implementing it as it will take me too much time. As we are faced with an acute breaking when using bash = 3.2 I am prepared to create a patch that fixes the octal issue. Please let me know if you will be fixing the issue properly by replacing echo -e with printf. If not I will create a fix for the octals issue as the breakage of bash 3.2 needs to be fixed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
On Wed, 2006-11-01 at 14:55 +0200, Pavel Tsekov wrote: I am beginning to wonther whether do we really want to escape the characters using echo or printf. For embedded backslashes etc. I suppose we do. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hello Thomas, On Wed, 2006-11-01 at 07:51 -0500, Thomas Dickey wrote: Before rushing off to change things to accommodate bash 3.2, it's worth checking if the fix will work with other shells. I'm not quite sure which fix you are referring to here. The temporary hack I send to this list should not break the other shells. All it does is add quoting of numbers for these shells. For the (temporary, echo -e) fix I had in mind even this change would be dropped. My idea was to add an ini option bash_oct_digits with possible values 0 (or unset) (automatically detect version via BASH_VERSION in the calling environment (actually querying the subshell seems a bit much) or fallback), 1 (compatibility mode, 4 digit octals with numbers quoted, for bash = 2.05b), 3 (legacy mode, only use 3 digit octals, no need to escape digits) and 4 (use 4 digit octals only, no need to escape digits, for bash = 3.2). Please let me know if there are volunteers to implement the proper solution (using printf) so I don't have to waste my time on a patch that is unnecessary. Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18042] cannot specify port number in shell link
Hello Pavel, On Wed, 2006-11-01 at 13:20 +0200, Pavel Tsekov wrote: IMO, it would be better if MC pops up an url specific dialog for each vfs if necessary so that the user could finer tune the connection. I think this would also help to add support for per connection settings i.e. use passive ftp for one connection and active for another. Instead of simple hacks we'd better go with well designed features. Agreed. But as Andrew also pointed out manpower is limited, so sadly we will sometimes have to use hacks if nobody is volunteering to invest time in the proper solution. They are not optimal, but in some cases better than not fixing breakage at all. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
On Wed, 2006-11-01 at 15:15 +0200, Pavel Tsekov wrote: The printf solution wouldn't be that hard to implement in fact. It may be even simpler. I can look at it. That would be nice. Thank you. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18042] cannot specify port number in shell link
Hello Pavel, On Wed, 2006-11-01 at 15:26 +0200, Pavel Tsekov wrote: This is not a task which requires tremendous efforts. It is just a matter of defining what we want to do and how we want to do it. And in the meantime there is an easy workaround - just set the port in ~/.ssh/config. Yes, with the we sometimes need hacks I was not referring to this issue. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hello Thomas, On Wed, 2006-11-01 at 08:38 -0500, Thomas Dickey wrote: One problem is that the user has to keep track (for the non-automatic workarounds) of the bash version. No. Default setting of 0 (or unset) of bash_octal_digits would fallback to option 1, which works for bash = 2.05b (in contrast to the current situation where by default only bash 3.2 will work). Only users of bash 2.05b will have to either export BASH_VERSION (iiuc BASH_VERSINFO is a set variable, not an environment var so unusable unless one directly queries the subshell) or set bash_octal_digits to 3. Pavel's the person to talk to (I maintain other programs including ncurses) - my point here was noting that bash 3.2 added other problems which are definitely _bugs_ in bash, and that it would not be good to cite 3.2 itself as a good example, but to focus on the feature. The issue of the octal length is independent of any bugs in bash 3.2 and will also exist for later versions. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] RPM vfs ignores conflicts
Hi Jindrich, On Tue, 2006-10-31 at 16:07 +0100, Jindrich Novy wrote: the current RPM vfs allows to see RPM package requires/provides and obsoletes but lacks an implementation of conflicts. The attached patch adds INFO/CONFLICTS to the RPM vfs so that conflicts are no more hidden. While you're at it, could you provide a similar patch for rpms please? I'll commit both in one go then. Thanks :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hi Pavel, On Mon, 2006-10-30 at 11:45 +0200, Pavel Tsekov wrote: IMO, if you intend to work on a fix you should follow the suggestion of the bash maintainer to switch over to using printf - not only for bash but for all cases. Of course a fallback may be required. After all according to bash maintainer: Use of `echo' in portable applications has been deprecated for years. See: http://www.mail-archive.com/bug-bash@gnu.org/msg02150.html Yes, I read that comment. However I'm not prepared to start breaking the functionality of shells that I never use. I guess the bash maintainer can give you insight on how to properly detect the bash version (if at all necessary). All I need to establish is whether the version is smaller than 3.2. I think I will use BASH_VERSINFO for this. If that array doesn't exist I will assume bash 3.2. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hi Christian, On Sat, 2006-10-28 at 23:48 +0200, Christian Hamar alias krix wrote: Attached patch implements this. This is not a proposition for a final solution, just a temporary hack for users of bash = 3.2. Do not use with versions of bash = 2.05b! Thx for the patch. It works with 3.2 (tested) If you can ride with BASH_VERSINFO then maybe this can be go to CVS. I suppose I will work with the BASH_VERSINFO environment variable. As you told me privately it was introduced in bash-2.0, so I suppose I will assume version 2 if the environment variable is not set. And if it will , then please dont forget to close #18136 :) Yes, I usually work via the bug system. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: MC problem with new bash 3.2
Hello Jochen, On Sun, 2006-10-29 at 11:58 +0100, Jochen Roderburg wrote: So only a few more remarks: I had already reported that issue to the bash-maintainers and their answer was: they had made the change in the echo -e behaviour to adhere to some current standards and they mean that no portable application should use the deprecated, non portable echo, but instead the portable printf. Well, I guess they are correct. Allowing only 4 digit octals instead of both 3 and 4 digit octals is definitely more consistent, which you can see from the fact that supporting both requires programmers to escape numbers following escaped characters (which in practice boils down to having to escape all numbers in strings using escaped characters). And btw, the effect on mc is even bigger in older versions (e.g. 4.5.xx) where not only special characters but all characters are quoted with octal digits in subshell_name_quote(). We do not support older version of mc. People using older versions should apply their own patches or ask their vendor to do so. The hack I provided should give you a starting point. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17874] Crashing inside liblow.c
Follow-up Comment #3, bug #17874 (project mc): I absolutelly don't know why mc passes here NULL. Are there ways to make mc behave better in this respect? If not please close invalid. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17874 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hi, If I understand the comments in the code only bash 2.05b has a problem with 4 number octals. Indeed a test with bash-3.0 confirms this. Since only alphas (not numbers) are not being escaped there are no problems with directories with names like a_0 for 2.05b bash = 3.2. Anyway, instead of testing for bash = 3.2 inside the bash loop we can suffice by adding a version check for bash 2.05b to the shell type test. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hi Christian, On Sat, 2006-10-28 at 10:22 +, Christian Hamar wrote: I just upgraded to bash-3.2 and now mc gives me error that Cannot change directory to XY.. . http://www.mail-archive.com/bug-bash@gnu.org/msg02150.html Fix needs to be made to subshell_name_quote() in the (subshell_type == BASH) block. Does bash always set the BASH_VERSINFO environment variable and is the syntax of this parameter portable over all versions (ie how do we best establish bashes version)? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hi,
On Sat, 2006-10-28 at 15:30 +0200, Leonard den Ottolander wrote:
Anyway, instead of testing for bash = 3.2 inside the bash loop we can
suffice by adding a version check for bash 2.05b to the shell type
test.
A quick and dirty hack for users of bash = 3.2 would be to just get rid
of the subshell_type == BASH test and block, and use the default block.
If we only escape alphas and not numbers in the default block this hack
should be safe for all users of bash 2.05b as explained in the
previous mail.
Attached patch implements this. This is not a proposition for a final
solution, just a temporary hack for users of bash = 3.2.
Do not use with versions of bash = 2.05b!
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
--- subshell.c.000 2006-05-08 23:11:48.0 +0200
+++ subshell.c 2006-10-28 15:40:46.0 +0200
@@ -745,29 +745,13 @@ subshell_name_quote (const char *s)
memcpy (d, cmd_start, len);
d += len;
-/*
- * Print every character in octal format with the leading backslash.
- * tcsh and zsh may require 4-digit octals, bash 2.05b doesn't like them.
- */
-if (subshell_type == BASH) {
for (; *s; s++) {
- /* Must quote numbers, so that they are not glued to octals */
if (isalpha ((unsigned char) *s)) {
*d++ = (unsigned char) *s;
} else {
- sprintf (d, \\%03o, (unsigned char) *s);
- d += 4;
- }
- }
-} else {
- for (; *s; s++) {
- if (isalnum ((unsigned char) *s)) {
- *d++ = (unsigned char) *s;
- } else {
sprintf (d, \\0%03o, (unsigned char) *s);
d += 5;
}
- }
}
memcpy (d, common_end, sizeof (common_end));
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17874] Crashing inside liblow.c
Update of bug #17874 (project mc): Status:None = Invalid Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?17874 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17967] Little bugs in FC utf-8 patches
Update of bug #17967 (project mc): Status:None = Invalid Assigned to:None = leonardjo Open/Closed:Open = Closed ___ Follow-up Comment #2: The UTF-8 patches are not being maintained by the mc team. Please report bugs at http://bugzilla.redhat.com. Closing invalid. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17967 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17773] ftpfs cannot list files with wrong date (e.g. Jan 01 2098)
Update of bug #17773 (project mc): Status:None = Fixed Open/Closed:Open = Closed Operating System:GNU/Hurd = All ___ Follow-up Comment #2: Reverted patch mentioned below as it is no longer needed. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17773 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17773] ftpfs cannot list files with wrong date (e.g. Jan 01 2098)
Update of bug #17773 (project mc): Assigned to:None = leonardjo ___ Follow-up Comment #1: Issue is most likely caused by a hack applied by Roland to is_year() in utilvfs.c. Date parsing has since been fixed (4 field dates are no longer acceptable as input). Reversely applying this patch should fix your issue: http://cvs.savannah.gnu.org/viewcvs/mc/vfs/utilvfs.c?root=mcr1=1.41r2=1.42 ___ Reply to this item at: http://savannah.gnu.org/bugs/?17773 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] bad highlighting of Requires in spec
Hi Jindrich, On Mon, 2006-09-04 at 15:53 +0200, Jindrich Novy wrote: 2006-09-04 Jindrich Novy [EMAIL PROTECTED] * spec.syntax: Highlight Requires(phase): correctly. s/phase/phrase The patch itself is somewhat inexact, but the same thing is done for Summary so it should be fine. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Make old esc mode key timeout configurable
Hi Pavel, On Fri, 2006-08-11 at 11:59 +0300, Pavel Tsekov wrote: At least change the name of the variable to something easier to type. Also a prefix showing that it is related to MC might be useful. If you could suggest a specific name I'm happy to comply. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] Accessing freed memory crash
Hi Mikulas, On Sat, 2006-08-12 at 20:02 +0200, Mikulas Patocka wrote: (btw. else retry = FALSE is useless in current code, but it doesn't hurt). I realized that after I did the commit. I still intend to take it out but wanted to get your reaction first in case other changes were still necessary. So it should work fine unless there's add_select_channel called with input_fd or gpm_fd And the whiles FD_ZERO (select_set). Ok. Just remove the else then. Thanks again. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Make old esc mode key timeout configurable
Hello Pavel, On Fri, 2006-08-11 at 11:59 +0300, Pavel Tsekov wrote: At least change the name of the variable to something easier to type. Also a prefix showing that it is related to MC might be useful. Please do. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] Accessing freed memory crash
Hello Mikulas, On Fri, 2006-08-11 at 01:49 +0200, Mikulas Patocka wrote: check_selects calls a callback when there is an event on handle. The callback itself can remove the event with delete_select_channel --- when it happens, check_selects accesses defunct p-next pointer and crash may happen. Committed using a do/while. Thanks for spotting and fixing. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Make old esc mode key timeout configurable
Hi Pavel, On Thu, 2006-08-10 at 12:37 +0300, Pavel Tsekov wrote: Maybe you've missed a patch I submitted some months ago regarding the same issue ? Yes, so it seems. Sorry. I've asked Denis to update his patch about 1 1/2 weeks ago. Too bad *you* didn't notice *that* ;) . If it's a serious improvement please resubmit. If you think we should take a different approach than using environment variables please discuss. Or if you feel like making the ftpfs timeout configurable please do and commit :-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17328] Conflicting shortcut alt-h in copy/move (german localisation)
Update of bug #17328 (project mc): Status:None = Fixed Assigned to:None = leonardjo Open/Closed:Open = Closed ___ Follow-up Comment #6: Ok. This is now fixed in CVS. I noticed a few more H hotkeys for hintergrund in the German dialogs. Haven't checked if these are in dialogs that use a history. Could you be so kind to check the dialogs and report clashes (preferably in batch). TIA. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17328 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Make old esc mode key timeout configurable
Hello Denis, On Mon, 2006-08-07 at 13:06 +0200, Denis Vlasenko wrote: Updated patch is attached. Please apply. Patch is committed. Next time be so kind to supply a patch that actually patches. 2 out of 5 hunks failed due to whitespace issues. Having to fix patches by hand is prone to error and wastes time. A change log entry is also appreciated. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Slower viewer [was Re: Shall we have a release?]
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? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Slower viewer [was Re: Shall we have a release?]
Hello Roland, On Wed, 2006-08-02 at 17:04 +0200, Roland Illig wrote: The file viewer has become much slower for large files, which annoys some users. What exactly are these regressions? If I view a 40MB text file on a 256MB system pressing End actually gets me to the end much faster than with a binary from June 2005 (5 vs 60 secs). Opening of the file is not significantly slower (if at all) than with the old version. Is this really an issue (that should stop us from doing a release)? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Shall we have a release?
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. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Shall we have a release?
Hello Roland, On Wed, 2006-08-02 at 17:04 +0200, Roland Illig wrote: The file viewer has become much slower for large files, which annoys some users. Is this something that can be fixed within a couple of weeks? Any leads on how to solve the issue? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
Hi Pavel, On Tue, 2006-07-18 at 16:54 +0300, Pavel Tsekov wrote: On Sat, 15 Jul 2006, Oswald Buddenhagen wrote: I also don't remember having major trouble with the subshell myself but then there are enough records in this mailing list and in other places which testify that the subshell is causing a lot of confusion. Maybe, but as you say, nothing serious has come up. A lot of efforts were thrown in an attempt to solve the unsolvable The shell is already running a command problem for example. Maybe we just don't understand this stuff well enough ;-) . This still feels like an incomplete logic issue to me. 2) The state of the subshell is not tracked. This could be improved but I don't think its worth the effort, IMO. So are you saying the state could be tracked better but should not be because it's too much effort? P.S. It's sad that not so many people joined the discussion :( As long as the input is valuable :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] Re: Small bug in mcedit
Hello Florin,
On Mon, 2006-07-03 at 13:42 +0300, Florin Asavoaie wrote:
form name=?= ??php echo this code is not highlighted correctly; ?
form name=?= ? ?php echo This code is highlighted perfectly.; ?
This can be sort of fixed by using context exclusive for quotes. See
the attached patch.
However, because the default context is not exclusive the stickiness
still remains in this case:
form name=?= ??php echo this code is not highlighted
correctly; ?
But as you probably want to embed a space after the quote in such cases
I suppose this fix is still rather useful.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
--- php.syntax.000 2006-03-18 21:45:47.0 +0100
+++ php.syntax 2006-07-16 03:18:19.0 +0200
@@ -8355,6 +8355,8 @@ context default
keyword , brightcyan
keyword : brightcyan
keyword ; brightmagenta
+keyword green
+keyword ' brightgreen
context exclusive ? ? cyan
keyword whole *; brightgreen
@@ -8375,7 +8377,7 @@ context exclusive // \n brown
context linestart # \n brown
spellcheck
-context green
+context exclusive green
spellcheck
keyword \\ brightgreen
keyword \\\n brightgreen
@@ -8391,6 +8393,6 @@ context green
keyword \\' brightgreen
keyword \\\{abtnvfr\} brightgreen
-context ' ' brightgreen
+context exclusive ' ' brightgreen
spellcheck
keyword \\' brightcyan
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: obsolete RPM tags highlighting
Hello Jindrich,
On Fri, 2006-07-14 at 19:52 +0200, Jindrich Novy wrote:
On Fri, 2006-07-14 at 15:33 +0200, Leonard den Ottolander wrote:
\{Gg\}\{Rr\}\{Oo\}\{Uu\}\{Pp\}
This is a joke, isn't it?
Just imagine a nice spec like this:
SuMmArY: Programs for backing up and restoring ext2/ext3 filesystems
nAMe: dump
veRSioN: 0.4b41
I agree it looks odd but it's valid syntax :-) .
At least the first capital letter should be mandatory upper-case
Although I don't really mind that we put some restrictions on the user
as to what capitalization is being highlighted I disagree with this. All
lowercase tags should be highlighted imo. Using all lowercase is rather
consistent and I encounter an occasional spec file that does this. And
why should we allow the decapitalization of the a in BuildArch but not
the B?
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: obsolete RPM tags highlighting
Hi Jindrich, On Sat, 2006-07-15 at 17:35 +0200, Jindrich Novy wrote: Because buildArch or buildPreReq in spec looks just wrong? ;-) As you might have guessed I was actually referring to buildarch and buildprereq. But I guess that if I prefer all lowercase tags to be highlighted I need to propose a patch here. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15461] vfs/extf for rpm/trpm query obsolete rpm tags
Follow-up Comment #4, bug #15461 (project mc): ? First you commit Jindrich's patch that highlights obsolete tags differently, and now you commit this patch removing these tags?? I think removing these tags from trpm makes sense: trpm is for browsing installed rpms, so I do not expect many people to be affected by this (although even in this case you could leave the highlighting for obsolete tags around. If they are not used they are not highlighted). However, to browse legacy rpms Jindrich's approach to highlight obsolete tags differently makes more sense. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15461 ___ Message sent via/by 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
Follow-up Comment #5, bug #15461 (project mc): Sorry for the confusion: Browsing rpms of course has nothing to do with (syntax) highlighting, so please ignore my last paragraph. The fact remains that keeping these obsolete tags around to be able to browse legacy rpms doesn't hurt. (FYI I do maintain legacy RHL 7.3 systems that still feature the Copyright tag.) ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15461 ___ Message sent via/by 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): Status: Fixed = Postponed ___ Follow-up Comment #7: Ok. I will (revert). (Introduction of EPOCH was indeed overdue.) See also http://mail.gnome.org/archives/mc-devel/2004-August/msg00040.html . The fact that I left in the COPYRIGHT tag was the result of (off list) discussions concluding to leave these legacy keywords around for a while longer. As they hardly consume any resources I'd say we review this issue in a year or 10 ;-p . ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15461 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Small bug in mcedit
Hello Florin, On Mon, 2006-07-03 at 13:42 +0300, Florin Asavoaie wrote: form name=?= ??php echo this code is not highlighted correctly; ? form name=?= ? ?php echo This code is highlighted perfectly.; ? This is an example of context stickyness that I reported earlier and tried to resolve contacting the original author of the editor/syntax code (Paul Sheer) (see the thread Double syntax context switch). Sadly his stance is the current implementation *is* the specification so he won't look into this issue. And since the code (apply_rules_going_right() iirc) is somewhat obscure I don't suspect this issue to be fixed any time soon. (Although in contrast to the authors stance I still consider this to be a bug and am willing to review patches people propose). Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Crash in mccolorer when choosing old syntax highlighting
Hi, (The patch by Pavel Tsekov did not fix the issue I was seeing, but then I didn't yet report what it was exactly.) How to reproduce: Edit a file Choose options-general menu Disable colorer Choose options-syntax highlighting boom (Backtrace is for mccolorer with Pavel's patch applied.) I suppose the switching to the menu's necessary for the old syntax highlighting doesn't yet work correctly. #0 0x080aaf1e in colorer_get_handle (edit=0x0) at syntax-colorer-wrapper.c:50 #1 0x080a97ab in colorer_free_syntax_rules (edit=0x0) at syntax-colorer.cpp:493 #2 0x080a7839 in edit_load_syntax (edit=0x0, pnames=0xbfaee638, type=0x0) at syntax.c:1203 #3 0x080a8ca5 in edit_syntax_dialog () at choosesyntax.c:66 #4 0x0807952c in menubar_execute (menubar=Variable menubar is not available. ) at menu.c:242 #5 0x08079d98 in menubar_callback (w=0x9697268, msg=WIDGET_HOTKEY, parm=10) at menu.c:326 #6 0x08063ebe in dlg_process_event (h=0x96722b8, key=10, event=0xbfaee6e4) at dialog.c:603 #7 0x080640d4 in run_dlg (h=0x96722b8) at dialog.c:785 #8 0x080a25f5 in edit_file (_file=0x9667908 Makefile, line=0) at editwidget.c:217 #9 0x0805e39a in do_edit_at_line (what=0x9667908 Makefile, start_line=0) at cmd.c:270 #10 0x0805e3e6 in do_edit (what=Variable what is not available. ) at cmd.c:289 #11 0x08095643 in buttonbar_call (bb=Variable bb is not available. ) at widget.c:2279 #12 0x08095831 in buttonbar_callback (w=0x966e0a8, msg=WIDGET_HOTKEY, parm=1004) at widget.c:2301 #13 0x08063d17 in dlg_process_event (h=0x9658298, key=1004, event=0xbfaee804) at dialog.c:614 #14 0x080640d4 in run_dlg (h=0x9658298) at dialog.c:785 #15 0x08078c16 in main (argc=1, argv=0xbfaefa24) at main.c:1675 Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Crash in mccolorer when choosing old syntax highlighting
Hello Igor, On Tue, 2006-06-27 at 18:08 +0400, Igor Russkih wrote: For me Pavel's patch fixes the problem. However Pavel diff-ed it with original mc source I believe because this it can fail to apply. +if (!edit) + return; + #if USE_COLORER colorer_free_syntax_rules(edit); return; #endif After applying Pavel's patch the if (!edit) ended up *after the (first) #if USE_COLORER. Bringing it to the front indeed fixes this crash. Thanks you both. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ 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: Need Info = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #27: Not sure why you didn't close it then. You should be able to. Closing. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #14155] 4.6.1: mouse wheel strangeness
Follow-up Comment #29, bug #14155 (project mc): Sorry. I took comment #26 as a we can close this report, and thought you still weren't aware you could close bugs. Well, you can reopen it yourself if you want. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[task #5673] Data Export #3 (bugs)
URL: http://savannah.gnu.org/task/?func=detailitemitem_id=5673 Summary: Data Export #3 (bugs) Project: GNU Midnight Commander Submitted by: leonardjo Submitted on: Thursday 22/06/06 at 13:54 Should Start On: Thursday 22/06/06 at 00:00 Should be Finished on: Friday 23/06/06 at 00:00 Category: None Priority: 5 - Normal Status: None Privacy: Private Assigned to: None Percent Complete: 0% Open/Closed: Open Effort: 0.00 ___ Details: A new export job has been registered. This task has been created to keep the project informed. However, only Leonard den Ottolander, that created the job, can remove the job itself. # JOB URL # Once the job will be done, it will be available at: https://savannah.gnu.org/export/mc/leonardjo/3.xml # JOB REMOVAL # Closing this task will not remove the job. To remove the job, Leonard den Ottolander must go at https://savannah.gnu.org/bugs/export.php?group=mc # JOB DETAILS # The SQL query will be: SELECT bug_id FROM bugs WHERE group_id=3521 (Note: We are aware this information is not tremendously user-friendly. This will be improved in future Savane releases) ___ Reply to this item at: http://savannah.gnu.org/task/?func=detailitemitem_id=5673 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander mod with Colorer-take5 syntax engine
Hello Igor, On Thu, 2006-06-22 at 14:17 +0400, Igor Russkih wrote: either during compilation time or in runtime - I meant this is already implemented. I should look for that switch then :) . No, just clean mc snapshot from ibiblio.org. Can you make it available to me? I am quite curious where the changes I observe came from. They are quite a few, and if they are not in CVS I'm curious how they ended up in the tarball. Is it technically possible to reimplement that c++ code in c? (This is just theoretical question, I don't ask you to do it.) It is possible to move this code to libcolorer side and implement plain C API from library side - however this'll take more time and I see no reason in doing this. My question was if it is technically possible to rewrite the cpp code for *mc* in c and (through trickery) still keep interface compatibility. A bit like linking Delphi (Pascal) to C code. This is possible through compiler switches changing the stack cleanup behaviour (and probably some alignment tricks). Again, I'm not asking you to do this, just inquiring about the theoretical possibility. It's a bit OT, I know ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[task #5674] Data Export #4 (bugs)
URL: http://savannah.gnu.org/task/?func=detailitemitem_id=5674 Summary: Data Export #4 (bugs) Project: GNU Midnight Commander Submitted by: leonardjo Submitted on: Thursday 22/06/06 at 14:10 Should Start On: Thursday 22/06/06 at 00:00 Should be Finished on: Saturday 24/06/06 at 00:00 Category: None Priority: 5 - Normal Status: None Privacy: Private Assigned to: None Percent Complete: 0% Open/Closed: Open Effort: 0.00 ___ Details: A new export job has been registered. This task has been created to keep the project informed. However, only Leonard den Ottolander, that created the job, can remove the job itself. # JOB URL # Once the job will be done, it will be available at: https://savannah.gnu.org/export/mc/leonardjo/4.xml # JOB REMOVAL # Closing this task will not remove the job. To remove the job, Leonard den Ottolander must go at https://savannah.gnu.org/bugs/export.php?group=mc # JOB DETAILS # The SQL query will be: SELECT bug_id FROM bugs WHERE group_id=3521 AND status_id IN (1) (Note: We are aware this information is not tremendously user-friendly. This will be improved in future Savane releases) ___ Reply to this item at: http://savannah.gnu.org/task/?func=detailitemitem_id=5674 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #14155] 4.6.1: mouse wheel strangeness
Follow-up Comment #25, bug #14155 (project mc): Ping. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Progress bar
Hello Pavel, On Thu, 2006-06-22 at 07:52 +0300, Pavel Tsekov wrote: Hampa's patch behaves exactly as described: [...] 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. [...] I got confused by bug 10507 that doesn't distinguish clearly between copy and move. The copy progress bar behaves as expected. (copy_dir_dir() and move_dir_dir() do not show a bytes or count bar, but this is expected as they do not attempt to make an estimate of the number and size of the copied/moved files.) Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #4970] add label highlighting to c.syntax
Update of patch #4970 (project mc): Status:None = Done Assigned to:None = leonardjo Open/Closed:Open = Closed ___ Follow-up Comment #9: Committed. Closing. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4970 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #4991] add .ipk extension to mc.ext
Update of patch #4991 (project mc): Category:None = Menu and associations Status:None = Done Open/Closed:Open = Closed ___ Follow-up Comment #2: Committed. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4991 ___ Message sent via/by 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,...)
Follow-up Comment #2, patch #4741 (project mc): Ping. Sorin, if you do not fix these patches this report will be closed. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4741 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander mod with Colorer-take5 syntax engine
Hello Igor, On Thu, 2006-06-22 at 17:55 +0400, Igor Russkih wrote: I've placed it at http://colorer.sourceforge.net/files/mc-2006-05-30-15.tar.gz Thanks. Well, that clears things up for me :-) . It turns out all the changes I observed are caused by the autogen step used to create the snapshots. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander mod with Colorer-take5 syntax engine
Hi Igor, On Thu, 2006-06-22 at 17:30 +0400, Igor Russkih wrote: It's a runtime option in editor's settings dialog. You'll find it easily ;) Yes, got it. But you've introduced a duplicate hotkey C. Please choose another one. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Where to report issues with mccolorer?
Hello Igor, Where do you want us to report issues with mccolorer? In the colorer bug system? (I'm seeing a crash when opening the syntax highlighting dialog for the old syntax highlighting.) Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander mod with Colorer-take5 syntax engine
Hello Igor, On Wed, 2006-06-21 at 16:50 +0400, Igor Russkih wrote: I'll be really glad to help to improve MC in this area, This looks really nice. I'm very exited. With just minor patching to the xml (introduction of ControlKeyword, eg if, else etc.) and a custom colour scheme I've already got the php syntax looking much like the original in mc (where can I send patches? Is there a mailing list for colorer?). Only have to look at the String type as we normally distinguish between single quoted (FixedString) and double quoted (VariableString) in php (and perl too for that matter). Although the startup of the viewer seems a bit slow with colorer this has much added value over the default syntax highlighting, and although I think we could well include the colorer hooks in the main mc tree I don't believe we should drop the existing highlighting, over even make colorer the default. Firstly the default syntax is more lightweight, which some people might prefer. Secondly the use of colorer requires the installation of a(n extra) third party library. If somebody is interested, attached is a full diff on MC tree to support colorer. Is this a fully functional patch? Much lighter than the diff I got diffing your tarball against CVS :) . In that patch I noticed a couple of things: - You got rid of the COPYING.LGPL file in vfs. I think this might be a mistake on your part. You might want to rectify that for your version. - In your version you got rid of the pipethrough files. This has no bearing on us as it's not in your patch. - There are a lot of fixes to the po files and some to the Russian and Serbian(?) man page. Please submit these to this list separately. - I noticed a CR here and there. There seem to be even more in the patch you sent. Please get rid of those (fe with dos2unix). - You made some fixes to the config files as well that seem same. Please submit those separately for review. - I noticed changes in vfs/samba/configure. Most of this are somewhat odd whitespace changes, but there appear to be some hunks at the top and bottom to actually do something. Please submit (not the whitespace) :) . - Why did you get rid of vfs/extfs/README.it? (not much of an issue) - There are a lot of added comments/fixes in config.h.in that I do not see in your patch. Please submit separately. For now I'm using sf.net SVN repository to store modified MC code. Information on how to access it: http://sourceforge.net/svn/?group_id=34855 Good to know. There are also some questions which I believe should be discussed. At first there is one C++ file in this mod (to link with c++ colorer code). As far as I understand MC uses C only. Is this a problem? Yes, it might. The overall approach towards accepted language constructs is a bit conservative to maintain compatibility with older systems. Would it be much work to rewrite these parts? Another is that this mod dynamically links to the libcolorer - this means that to use it, colorer library should be installed in system. This introduces MC additional dependency. This is why I do not want to make colorer the default. I think this is something we should leave to the distributions. to get syntax highlighting in the viewer too That's a good idea, I'll try investigate it in near time. That would be great. Thanks a lot! Leonard. P.S. Could you please set your mail client to produce plain text mails and use an indentation character and a replying to line for quotes? -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander mod with Colorer-take5 syntax engine
Hello Pavel, On Wed, 2006-06-21 at 17:26 +0300, Pavel Tsekov wrote: Yes it will take a lot of work - colorer is written entirely in C++ . Thus there is a thin wrapper to translate from C to C++ and vice versa. In my opinion this is not a big deal and a necessary sacrifice. I'm not sure what you say here: Is it a necessary sacrifice to port syntax-colorer.cpp to c or is it a necessary sacrifice to include c++ code into the tree? I'd rather go for the first option. This can be achieved with configure too - I have code for that too. All it needs is the current default in the patch to change. I still haven't looked at the patch that Igor sent today but I'll do that as soon as I get some free time. I am willing to make the necessary changes to MC to adopt Igor's patch. Maybe Igor is just as willing to make some changes to the patch for mc to adopt it ;) . I think patch has great value. We totally agree then :-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16303] More functionally u7z
Follow-up Comment #4, bug #16303 (project mc): It's easier to see what changed (and if there are unwanted regressions) if you patch the existing version instead of writing a new version from scratch. So if you want to get any improvements considered for inclusion you will have to rewrite your patch. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16303 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ 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 #7, bug #16452 (project mc): Any patches forthcoming? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16452 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16383] Build system does not allow cross compiling
Follow-up Comment #1, bug #16383 (project mc): Please provide a patch. Thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16383 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15621] file/dir entries with international characters mess up the columns
Update of bug #15621 (project mc): Status:None = Duplicate Assigned to:None = leonardjo Open/Closed:Open = Closed ___ Follow-up Comment #2: This is a duplicate of bug 7936 and bug 15100. Please check for existing bug reports before submitting. If you do submit please specify your platform, the version of mc used and if any patches have been applied. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15621 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Progress bar
Hello Pavel, Looking at bugs 10507 and 13100. The patch from Hampa Hug that you've committed should fix the issue for moving files. Does it also fix the issue when copying files? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #13100] Bytes and Count progess bars when moving multiple files
Update of bug #13100 (project mc): Status:None = Duplicate Assigned to:None = leonardjo Open/Closed:Open = Closed ___ Follow-up Comment #1: This is a duplicate of bug 10507. Should be fixed by the patch from Hampa Hug to file_move_move() in file.c. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13100 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander mod with Colorer-take5 syntax engine
Hello Igor, On Wed, 2006-06-21 at 23:26 +0400, Igor Russkih wrote: On 6/21/06, Leonard den Ottolander [EMAIL PROTECTED] wrote: Colorer library can be disabled either during compilation time Switching at run time would be nice. At least as a startup option. Just a single ru.po file with a few additions. And sr.po. For all the next comments it seems to be a misunderstanding (possibly because my diff is based on MC-2006-05-30-15 snapshot, not the latest one). These are no misunderstandings, just differences I noticed between mccolorer and mc-CVS. I already filtered out some m4 related makefile issues. - There are a lot of added comments/fixes in config.h.in that I do not see in your patch. Please submit separately. These are comments and fixes in your mccolorer, not available in CVS. Are you using patches from others? - You got rid of the COPYING.LGPL file in vfs. I think this might be a mistake on your part. You might want to rectify that for your version. For some reason this file got lost in your mccolorer tarball. - You made some fixes to the config files as well that seem same. Please submit those separately for review. - I noticed changes in vfs/samba/configure. Most of this are somewhat odd whitespace changes, but there appear to be some hunks at the top and bottom to actually do something. Please submit (not the whitespace) :) . These are patches you seem to be using that are not in CVS. This is why I ask you to submit them for review. I'll upmerge with latest CVS MC revision and resend it. The CVS tarball I'm using is only 2 weeks newer than yours. I'm not speaking of the recent changes to CVS. The main problem with this is that syntax-colorer.cpp file makes direct connection between mc editor data and colorer's code. Technically it is possible to extract a kind of 'generic' C API and include it on library side. In this case MC will have pure C codes. Is it technically possible to reimplement that c++ code in c? (This is just theoretical question, I don't ask you to do it.) From the other side this will not release MC from libcolorer dependency - and this means that if user wants to compile and use mc-colorer, he anyway should have C++ environment. I mean I see no reason to eliminate that C++ code from MC: those who have C-only environments can just disable colorer's support in compile time. Yes, I guess you are right. We might want to put the colorer code in a different directory though. P.S. Could you please set your mail client to produce plain text mails and use an indentation character and a replying to line for quotes? sorry, fixed. Thanks :) Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Progress bar
On Wed, 2006-06-21 at 21:55 +0300, Pavel Tsekov wrote: Does it also fix the issue when copying files? No. Seems to work fine though. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Snapshots availability
Hi, Who is the creator of the two weekly snapshots found at http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ ? Pavel? Miguel? Could you please keep a couple of months worth of snapshots around? I couldn't find the May 30th snapshot when I wanted to compare it with mccolorer. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[task #5671] Data Export #2 (bugs)
URL: http://savannah.gnu.org/task/?func=detailitemitem_id=5671 Summary: Data Export #2 (bugs) Project: GNU Midnight Commander Submitted by: leonardjo Submitted on: Thursday 22/06/06 at 01:05 Should Start On: Thursday 22/06/06 at 00:00 Should be Finished on: Friday 23/06/06 at 00:00 Category: None Priority: 5 - Normal Status: None Privacy: Private Assigned to: None Percent Complete: 0% Open/Closed: Open Effort: 0.00 ___ Details: A new export job has been registered. This task has been created to keep the project informed. However, only Leonard den Ottolander, that created the job, can remove the job itself. # JOB URL # Once the job will be done, it will be available at: https://savannah.gnu.org/export/mc/leonardjo/2.xml # JOB REMOVAL # Closing this task will not remove the job. To remove the job, Leonard den Ottolander must go at https://savannah.gnu.org/bugs/export.php?group=mc # JOB DETAILS # The SQL query will be: SELECT bug_id FROM bugs WHERE group_id=3521 (Note: We are aware this information is not tremendously user-friendly. This will be improved in future Savane releases) ___ Reply to this item at: http://savannah.gnu.org/task/?func=detailitemitem_id=5671 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Bugzilla submits only against = 4.6.1
Hello Pavel, On Mon, 2006-06-19 at 17:49 -0400, Pavel Roskin wrote: Some bugs can be more long-lived than you may think. I believe the quality of the bug report should be judged not only by the version. Bugs against old versions should be discouraged, but not outright forbidden. Besides, there is only one bug filed for older than 4.5.55. I didn't mean old bugs should be removed from the bug list. I just feel it doesn't make much sense for people to file new bugs against anything older than 4.6.1. There is no added value to let people add bugs against older versions. If the issue no longer exists it's just wasted time, and if it does still exist the reporter should make the effort to verify the issue indeed still exists in 4.6.1 or later. None is hardcoded, All versions is not. I think all version is a valid value in some cases. Yes, but only if you keep all the other versions as valid options. If we'd drop anything but latest stable and CVS there's not much use leaving all versions around. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16762] Cannot compile mc-2006-06-05-20
Follow-up Comment #23, bug #16762 (project mc): If coreutils configure tests are modified to include tests for: 1) the presence of field f_fstypename in struct statvfs 2) the type of the first argument ot getmntinfo() we will remove the homebrew tests from AC_GET_FS_INFO and use those provided by coreutils. Have you contacted the coreutils maintainers about this? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16762 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16762] Cannot compile mc-2006-06-05-20
Follow-up Comment #21, bug #16762 (project mc): If Roland doesn't feel the need to add any remarks to this approach I suppose this patch can be submitted and this report closed. (I did not verify the code other than glancing over it, but I trust it to be ok ;) .) ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16762 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16871] czech translation - description overlaps in the chmod dialogue
Update of bug #16871 (project mc): Status:None = Need Info Assigned to:None = leonardjo ___ Follow-up Comment #1: Please provide a patch. Mske sure you use the correct character set in the file. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16871 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16872] ftpfs lists directories begining with '2006 ' incorrectly
Update of bug #16872 (project mc): Status:None = Duplicate Assigned to:None = leonardjo Open/Closed:Open = Closed ___ Follow-up Comment #1: Be so kind to check for exisiting reports before submitting new reports. This is a duplicate of 10645 and 4327. This issue has been fixed in CVS. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16871] czech translation - description overlaps in the chmod dialogue
Update of bug #16871 (project mc): Status: Need Info = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #3: Ok. Closing invalid as the issue didn't exist anymore when the issue was reported. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16871 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16829] Crash when formatting paragraph
Update of bug #16829 (project mc): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #4: Pavel Tsekov committed patches to fix this issue. Closing. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16829 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc bugs
Hello Sipieter, On Wed, 2006-06-14 at 15:50 +0900, sipieter nicolas wrote: but, after a while working like that, mc seems unable from time to time to connect to the ftp server. i even get seg fault, or it just fail to connect randomly.. Connection failures are not necessarily a problem with mc (not saying the ftp code is perfect though ;) ). However, if you do see segmentation faults please open a bug report at http://savannah.gnu.org/bugs/?group=mc and attach a backtrace. Don't forget to mention system information and please do *not* report bugs against mc versions before 4.6.1. (Use ulimit -c 9 to enable core dumps on your system. Use gdb path to mc core file and the bt command to get a backtrace.) Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Bugzilla submits only against = 4.6.1
Hello Pavel, IMO it doesn't make much sense for people to be able to report bugs against mc versions older than 4.6.1. I presume most developers will agree with me (please protest if not). Could you please update the Savannah bugs Release drop down menu to only contain the following elements? older than 4.6.1 (upgrade first!) 4.6.1 current (CVS or snapshot) I don't think we need the entries All versions and None but these might be hard coded default entries. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Symlink attack in file.c?
Hi, Something I came across a couple of times this week, just now in relation to an RFE regarding file permissions on copying fat files in RHs bugzilla (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195614): http://cvs.savannah.gnu.org/viewcvs/mc/src/file.c?root=mcr1=1.28r2=1.29 A commit by pavel (Machek?) who added the remark FIXME: You have security hole here, btw. Imagine copying to /tmp and symlink attack :-( Is there anybody that can explain to me what he's concerned about and if that is still an issue? If so this is a rather long standing hole... If not, let's get rid of that warning. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16829] Crash when formatting paragraph
Update of bug #16829 (project mc): Status: Invalid = None Assigned to:None = leonardjo Open/Closed: Closed = Open Operating System:GNU/Hurd = All ___ Follow-up Comment #3: Turns out to be a general mc issue after all: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194562 Jindrich Novy proposes the following solution: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=131038 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16829 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Dialogs, hotkeys and capitalization
Hi, This is a bit of a minor issue, but Pavel Tsekov brought it up when I changed a duplicate hotkey in the sort order dialog. I changed Change time to CHange time thus capitalizing the hotkey, but also leaving the first letter of the phrase capitalized. Although the double capitalization might look somewhat odd it emphasizes the hotkey and I think the capitalized first letter looks nicer. The most widely used approach in the menus and dialogs is to only capitalize the (highlighted) hotkey (cHange time), but this is implemented inconsistently, which is most obvious in the Command menu. I have no idea how we should reach an agreement on this (vote??), but I think it's a good idea to decide on a format so the menus and dialogs will look more consistent. The three options I think are most appropriate are: No added capitalization of hotkeys (Change time) (no emphasis apart from colourization) Add capitalization to hotkeys (CHange time) (double capitalization) Only capitalize the hotkey (cHange time) (missing capitals in first position) Opinions? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: utf8 patch for mc, slang 2 version
Hello Jindrich, On Thu, 2006-06-08 at 20:13 +0200, Egmont Koblinger wrote: I've just upgraded to slang-2 in our distro and also updated the UTF-8 patches to mc-4.6.1 (based on SUSE's version). It was easier than I thought it would be. I was glad to see that you had applied plenty of my patches in SUSE (those named 00-*). Please take a look at here again: https://svn.uhulinux.hu/packages/dev/mc/patches/ Please take notice. It would probably be good if Vladimir and you could keep your UTF-8 patch sets in sync. It just seems wasted effort to do this in two places independently. Some inter-distro communication is not going to hurt. Maybe these patches should be centrally maintained in a contribs tree. Egmonts patches are worth looking at. I've blatantly ignored pushing them to you as I'd expected you to integrate them over time. I've probably not made it clear enough to you before that these patches are worth considering. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Fwd: [Bug 194777] New: mc hangs when copying file with no read perm over fish]
Hi, I can confirm this behaviour. Probably fish needs to test permissions before attempting to copy. Leonard. Forwarded Message From: bugzilla at redhat.com To: leonard-rh-bugzilla at den.ottolander.nl Subject: [Bug 194777] New: mc hangs when copying file with no read perm over fish Date: Sat, 10 Jun 2006 09:19:40 -0400 Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194777 Summary: mc hangs when copying file with no read perm over fish Product: Fedora Core Version: fc5 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: mc AssignedTo: jnovy at redhat.com ReportedBy: stsp at aknet.ru CC: leonard-rh-bugzilla at den.ottolander.nl Description of problem: If I try to copy the file over the ssh connection (fish) for which there is no read permission, mc hangs. Version-Release number of selected component (if applicable): mc-4.6.1a-13.FC5 How reproducible: always Steps to Reproduce: 1. Make an ssh connection with mc, log is as user, not root 2. Try to read/copy some file, like /etc/shadow, for which you don't have the read permission. Actual results: mc hangs Expected results: mc displays the permission denied error. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: FTP: Cannot change to write-only directory
Hi, On Tue, 2006-06-06 at 22:14 +0200, Leonard den Ottolander wrote: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194277 False alarm. The issue seems to be recently fixed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16762] Cannot compile mc-2006-06-05-20
Follow-up Comment #1, bug #16762 (project mc): Does this fix your issue? ___ Additional Item Attachment: File name: mountlist.c.patch Size:0 KB Define HAVE_F_FSTYPE if HAVE_STRUCT_STATFS_F_FSTYPENAME is defined (regardless of HAVE_STATVFS) http://savannah.gnu.org/bugs/download.php?file_id=10135 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16762 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
FTP: Cannot change to write-only directory
From Red Hat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194277 Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
