[bug #17268] Shift+Enter weirdness
Update of bug #17268 (project mc): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #7: Closing it as WONTFIX. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17268 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17568] Cannot compile mc-2006-08-29
Follow-up Comment #1, bug #17568 (project mc): http://mail.gnome.org/archives/mc-devel/2006-August/msg00069.html ___ Reply to this item at: http://savannah.gnu.org/bugs/?17568 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Mouse support bugs and a couple of feature requests
On Sat, 2 Sep 2006, Stephan Sokolow wrote: 3. The -x option prevents gpm from working at the console. Why would you do that ? As for the feature requests: 1. could you please add an option to start with MC hidden (equivalent to starting normally and then pressing Ctrl+o) so I can stick it at the end of my .bashrc comfortably? But then you would end up in another shell - the one started by MC and not in your login shell. Do you really want that ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Mouse support bugs and a couple of feature requests
On Sat, 2 Sep 2006, Stephan Sokolow wrote: First, the bug: 1. Running mc inside screen at the Linux console prevents gpm mouse support from working. Seems to be a gpm problem. See what I've got in my syslog: *** warning [client.c(183)]: Failed gpm connect attempt by uid 500 for vc 0 I ran MC under debugger in linux console both with screen and in plain console. When I am not running screen everything is normal. If I start screen I get the above message both in syslog and printed on the console ... but the Gpm_Open() call doesn't report error. I'll try to research why this happens but it is obvious that this problem is not MC related. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Mouse support bugs and a couple of feature requests (fwd)
Stephan, please, keep the discussion on the mailing list. I am forwarding your messages there. -- Forwarded message -- Date: Mon, 4 Sep 2006 05:10:12 -0400 From: Stephan Sokolow [EMAIL PROTECTED] To: Pavel Tsekov [EMAIL PROTECTED] Subject: Re: Mouse support bugs and a couple of feature requests On Monday September 4, 2006 04:41, you wrote: On Sat, 2 Sep 2006, Stephan Sokolow wrote: 3. The -x option prevents gpm from working at the console. Why would you do that ? Because -x is the only way to get mouse support working inside my Yakuake--bash--screen--mc stack for some reason. My more important complaint is that I can't get console mouse support when running MC inside screen and yet every other GPM-supporting app works fine. As for the feature requests: 1. could you please add an option to start with MC hidden (equivalent to starting normally and then pressing Ctrl+o) so I can stick it at the end of my .bashrc comfortably? But then you would end up in another shell - the one started by MC and not in your login shell. Do you really want that ? My system already triggers a bash -- screen -- bash stack on login because I've been too busy to solve my screen won't work as a login shell problem. I just want an easy way to automate the start MC hidden part of a bash -- screen - mc -- bash stack. If I can find the time to fix screen, I'll prune it down to screen -- mc -- bash. -- deitarion/SSokolow Stephan Sokolow SSokolow.com Webmaster ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Mouse support bugs and a couple of feature requests (fwd)
On Mon, 4 Sep 2006, Pavel Tsekov wrote: -- Forwarded message -- Date: Mon, 4 Sep 2006 06:03:52 -0400 From: Stephan Sokolow To: Pavel Tsekov Subject: Re: Mouse support bugs and a couple of feature requests On Monday September 4, 2006 05:15, you wrote: On Sat, 2 Sep 2006, Stephan Sokolow wrote: First, the bug: 1. Running mc inside screen at the Linux console prevents gpm mouse support from working. Seems to be a gpm problem. See what I've got in my syslog: *** warning [client.c(183)]: Failed gpm connect attempt by uid 500 for vc 0 I ran MC under debugger in linux console both with screen and in plain console. When I am not running screen everything is normal. If I start screen I get the above message both in syslog and printed on the console ... but the Gpm_Open() call doesn't report error. I'll try to research why this happens but it is obvious that this problem is not MC related. Screen uses a pseudo-terminal pair to communicate with the shells it starts. As such when you start MC it is running on the pseudo terminal slave device - /dev/pts/1 for example. It is screen that is running on the virtual console device (the real terminal) and not MC. gpm cannot handle mouse events on anything other than Linux virtual console. So requests from MC for mouse events on /dev/pts/1 should fail ... but there is a patch in the RedHat version of gpm that removes a check which is supposed to catch that condition. I guess you are using Fedora, right ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] bad highlighting of Requires in spec
On Mon, 4 Sep 2006, Jindrich Novy wrote: 2006-09-04 Jindrich Novy jnovy at redhat dot com * spec.syntax: Highlight Requires(phase): correctly. The patch does more than that. I guess that if I commit that someone would start complaining about it... So, I will for two more days and commit after that. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Mouse support bugs and a couple of feature requests (fwd)
-- Forwarded message -- Date: Mon, 4 Sep 2006 05:10:12 -0400 From: Stephan Sokolow [EMAIL PROTECTED] To: Pavel Tsekov [EMAIL PROTECTED] Subject: Re: Mouse support bugs and a couple of feature requests On Monday September 4, 2006 04:41, you wrote: On Sat, 2 Sep 2006, Stephan Sokolow wrote: 3. The -x option prevents gpm from working at the console. Why would you do that ? Because -x is the only way to get mouse support working inside my Yakuake--bash--screen--mc stack for some reason. My more important complaint is that I can't get console mouse support when running MC inside screen and yet every other GPM-supporting app works fine. Wait, wait... I am confused now. What do you mean by console ? The linux console (virtual console) or a terminal emulator in general ? Basically, the '-x' option should be used when you know that your terminal emulator is xterm-like but it doesn't set the TERM variable to xterm i.e. as a hint to MC that it should expect xterm features. One of these features is the xterm mouse reporting - it has nothing to do with gpm. xterm like terminals (when instructed to do so) generate special escape sequences which indicate that a mouse event occured. MC reads these sequences (via its standard input stream) and interprets them when it thinks that it is runnning under xterm-like terminal emulator. This is different from gpm mouse event reporting - in this case MC must be linked to the gpm client library to read mouse events. gpm mouse reporting as used by MC is useful only when running MC on the linux virtual console (linux console). I've tried to run MC under yakuake and the mouse works as expected. If it doesn't work for you it is most likely because the TERM variable is set to something different from xterm. This is why you have to pass the -x option to MC. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: patch for viewing DjVu files
On Thu, 7 Sep 2006, Nerijus Baliunas wrote: Anyone? It's really a simple patch, and Changelog is not really needed, but if you want it: 2006-09-07 Nerijus Baliunas [EMAIL PROTECTED] * mc.ext.in: Add support for .djvu files. I am just not sure what is the current policy for adding entries to mc.ext.in. Otherwise its fine with me. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Current CVS compile fails on Darwin with error in mountlist.c
On Thu, 24 Aug 2006, Frank Joerdens wrote: On 8/23/06, Pavel Tsekov [EMAIL PROTECTED] wrote: [] Comment the line containing MOUNTED_GETMNTINFO_STATVFS in your config.h file. I have to fix this but have been quite busy in the last few weeks. Cool, it works. Thanks! With the current CVS version everything should work just fine. Please, test. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: patch for viewing DjVu files
On Thu, 7 Sep 2006, Nerijus Baliunas wrote: On Thu, 7 Sep 2006 19:46:39 +0400 (MSD) [EMAIL PROTECTED] wrote: I use kdvi for djvu, it more handy then djview: Open=if [ $DESKTOP_SESSION = kde ]; then (nohup kdvi %f ); else (nohup djview %f ); fi No problem about using kdvi with me, but why nohup? No entry in mc.ext.in currently has it. Does everyone agree ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17220] mc -a (stickchars) is gone
Follow-up Comment #2, bug #17220 (project mc): Ping! ___ Reply to this item at: http://savannah.gnu.org/bugs/?17220 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Mouse support bugs and a couple of feature requests
On Mon, 11 Sep 2006, Morten Bo Johansen wrote: Stephan Sokolow [EMAIL PROTECTED] wrote: 2. Running mc inside screen inside Konsole (or Yakuake) prevents mouse support unless explicitly run with the -x option. You will notice that If you have your $TERM set to something like screen(.*) then mouse actions do not work, this goes not only for mc, but for any other app (in my experience). However, if you set it to xterm(.*), then it works. I do not know if the reason for this is in screen, the terminal or the applications, but it is a little annoying. MC recognizes only a couple of terminals as capable of xterm mouse reporting. It reads the value of the TERM variable and compares it a against a fixed list of strings - i.e. xterm, Eterm, etc. An alternative approach would be to to make this list user configurable as suggested here: https://savannah.gnu.org/bugs/?16910 ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17269] localized headers in .mc/history
Follow-up Comment #3, bug #17269 (project mc): I looked at that problem and the solution is pretty easy. Still I'd like to discuss the issue with anyone interested so we can find the best way to solve the problem. Most of the problematic entries are created by an invocation of the function nice_cd() located in src/cmd.c . Its first argument is a string to be used as the heading of the dialog. The same string is also used to form the name of the section in the history file where entries fed to the input field of the dialog will be stored. A typical call to nice_cd() looks like this: nice_cd (_(Title string), ...) So as you can see nice_cd() is passed a translated string - this is why a translated section name is written to the history file. However this is unnecessary since later the title string is translated one more time when quick_dialog() is invoked to show the dialog. So, one way to solve the problem is to change nice_cd() invocations like this: nice_cd (N_(Title string), ...) However, this may not be the best solution since the programmer must know that it should call nice_cd () with N_() instead of _(). So, maybe a better way to solve the problem would be to add a new argument to nice_cd() which will hold the history section name. Any thoughts ? ___ Reply to this item at: http://savannah.gnu.org/bugs/?17269 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17269] localized headers in .mc/history
Follow-up Comment #5, bug #17269 (project mc): My last comment may be slightly misleading. To clarify: nice_cd() and others use fg_input_dialog_help() which takes care of displaying the input dialog and derives history file section names from the input dialog heading. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17269 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17269] localized headers in .mc/history
Follow-up Comment #6, bug #17269 (project mc): I think I'll proceed as following: 1) Currently fg_input_dialog_help() assumes that it is passed translated strings. I won't change that because some of the callers pass as an argument a string which is the result of sprintf() on translated template string. However, I'll change fg_input_dialog_help() to prevent the translation of the already translated strings. Additionally I'll add comments to indicate that fg_input_dialog_help() and any wrappers must take translated strings. 2) Next I'll change fg_input_dialog_help() to take a new argument - the history section name. Then I will adjust all callers. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17269 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17568] Cannot compile mc-2006-08-29
Update of bug #17568 (project mc): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: I am closing as FIXED. Still if you see build failures feel free to reopen. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17568 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17269] localized headers in .mc/history
Follow-up Comment #7, bug #17269 (project mc): I am attaching a patch which adds a new argument to fg_input_dialog_help() - the history section name. I've adjusted all callers (hopefully) to pass the new argument. Please, test the patch. The patch should be applied against latest CVS. This patch doesn't attemt to change the section names. However, the current choice for section names is really bad, IMHO. Maybe now is the time to rename those names for good. I'd like to hear your opinion on that matter too. ___ Additional Item Attachment: File name: history-section-names.patchSize:17 KB http://savannah.gnu.org/bugs/download.php?file_id=10799 ___ Reply to this item at: http://savannah.gnu.org/bugs/?17269 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17823] hint changed when the window is resized
Update of bug #17823 (project mc): Status:None = Confirmed Assigned to:None = ptsekov Operating System: GNU/Linux = All ___ Follow-up Comment #1: I can confirm this. It seems this is the result of a set of patches, aiming to fix a bug in the hintbar code, applied back in December 2002 and February 2003... I have an idea how to fix it but I want to do my homework so that I won't introduce a new bug fixing that one. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17823 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17874] Crashing inside liblow.c
Follow-up Comment #2, bug #17874 (project mc): The crash that you see has nothing to do with MC. The backtraces do not provide any evidence to support your theory. It must be an gpm issue. ___ 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
Follow-up Comment #1, bug #17967 (project mc): As you correctly noted this bug report belongs to the Redhat bugzilla. The UTF-8 patches applied to MC are common between all distros which use them. ___ 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
Removing rxvt.c ?
Hello, What do you think about removing rxvt.c ? It seems that the patch required to support this feature never was accepted in rxvt... And it also seems to be unnecessary with the current version of MC (which is 5 years old). Any thoughts ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17220] mc -a (stickchars) is gone
Update of bug #17220 (project mc): Category:None = Screen output ___ Follow-up Comment #4: Hmmm. It happens only with UTF-8 locales and UTF-8 capable terminals. I guess it has something to do with UTF-8 version of MC (not supported here) or maybe the RedHat supplied S-Lang library or the terminal emulator itself. Anyway, I think filing this bug report against FC bugzilla would be more appropriate. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17220 ___ 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.
Hello, On Sun, 29 Oct 2006, Leonard den Ottolander wrote: 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. 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 I guess the bash maintainer can give you insight on how to properly detect the bash version (if at all necessary). ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18042] cannot specify port number in shell link
On Wed, 1 Nov 2006, Leonard den Ottolander wrote: 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. The port clearly belongs to the url, as do the hostname, the username, the password and the location. Options are hardly candidates to become part of the url. 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. ___ 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 Tue, 31 Oct 2006, Leonard den Ottolander wrote: 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. This is a rather strange statement. As a developer you should try to go beyond your personal preferences. Changes to the subshell shall be tested with all supported shells and on as many platforms as possible. From Chet Ramey's statement it is clear that using printf is the right thing to do. ___ 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, 1 Nov 2006, Thomas Dickey wrote: On Wed, 1 Nov 2006, 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. Changes to the subshell shall be tested with all supported shells and on as many platforms as possible. From Chet Ramey's statement it is clear that using printf is the right thing to do. That's his statement. Jim Meyering's comment is more reasonable. His comment is related to coreutils and not bash. Anyway, he still agrees that printf should be used. If this is the way to go why shall we wait ? ___ 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, 1 Nov 2006, Thomas Dickey wrote: On Wed, 1 Nov 2006, Pavel Tsekov wrote: On Wed, 1 Nov 2006, Thomas Dickey wrote: On Wed, 1 Nov 2006, 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. Changes to the subshell shall be tested with all supported shells and on as many platforms as possible. From Chet Ramey's statement it is clear that using printf is the right thing to do. That's his statement. Jim Meyering's comment is more reasonable. His comment is related to coreutils and not bash. Anyway, he still agrees that printf should be used. If this is the way to go why shall we wait ? He's recommending it for new scripts, not recommending that one rewrite existing scripts (and by noting that other shells retain the existing treatment, is pointing out a problem). Ok. Since I am not native english speaker I cannot judge whether he is recommending it or not. In any case I can see why keeping the old behaviour of 'echo' is important for large scripts, however what we have in MC is nothing as big. I just feel that what Leonard is proposing is a hack and not an actual solution. Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in existing scripts to bother with 3.2.x). Does this mean that you think that bash 3.3 will reinstantiate the old behaviour ? ___ 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, 1 Nov 2006, Thomas Dickey wrote: On Wed, 1 Nov 2006, Pavel Tsekov wrote: Ok. Since I am not native english speaker I cannot judge whether he is recommending it or not. In any case I can see why keeping the old behaviour of 'echo' is important for large scripts, however what we have in MC is nothing as big. I just feel that what Leonard is proposing is a hack and not an actual solution. Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in existing scripts to bother with 3.2.x). Does this mean that you think that bash 3.3 will reinstantiate the old behaviour ? Not for this (echo -e is a dead issue, though some of the discussion there touches on other problems). But it would be reasonable to expect it to fix the syntax errors. Before rushing off to change things to accommodate bash 3.2, it's worth checking if the fix will work with other shells. The fix which Leonard proposes would not affect the other supported shells. Look at subshell_name_quote() in subshell.c. I am beginning to wonther whether do we really want to escape the characters using echo or printf. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18042] cannot specify port number in shell link
On Wed, 1 Nov 2006, Leonard den Ottolander wrote: 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. 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. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: find in viewer
On Thu, 2 Nov 2006, Nerijus Baliunas wrote: Hello, could this patch please be committed to cvs (I am attaching it for your convenience)? BTW, how this patch works when two mc are running? If I search in 1st mc, then in 2nd mc, and then again in 1st mc, what will I get - last text from 1st or 2nd? I'd prefer from 1st, i.e. different mc sessions to be independent. This patch is not as good. Something else should be used. Reverting the original code that broke this feature might be better option for now. I'll try to do something about it till the weekend. ___ 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 Mon, 27 Nov 2006, Jindrich Novy wrote:
there is a breakage in util.c and utilunix.c related to temporary files
creation. The problem is that if a directory for temporary files cannot
be created mc ends up in infinite loop caused by:
tmpbase = concat_dir_and_file (mc_tmpdir (), prefix);
in mc_mkstemps() which then calls mc_tmpdir() back infinitely and ends
up in a stack underflow.
The attached patch fixes it as it disables the creation of the temporary
files when the temp. directory couldn't be created.
Ok. But... what happens if any of the following
error conditions occur ?
if (lstat (buffer, st) == 0) {
/* Sanity check for existing directory */
if (!S_ISDIR (st.st_mode))
error = _(%s is not a directory\n);
else if (st.st_uid != getuid ())
error = _(Directory %s is not owned by you\n);
else if (((st.st_mode 0777) != 0700)
(chmod (buffer, 0700) != 0))
error = _(Cannot set correct permissions for directory
%s\n);
} else {
Wouldn't it cause the same loop as when mkdir() fails ?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key
Hello Grigory,
On Wed, 29 Nov 2006, Grigory Trenin wrote:
Here is a detailed description how to reproduce it:
1) Open the Help Contents (press F1, Tab, Enter)
2) Navigate some lines forward (press End or PageDown several times)
3) Enter the selected topic (press Enter)
4) Return back (press right arrow)
5) Move to the top of Contents (press Home)
6) Now try navigating the Contents using the up and down arrow keys.
(for example, press down arrow for 5 times, then press up arrow).
You will notice that when you press up arrow key the selection
jumps to the top of window.
I can confirm the problem.
The problem is in the help_handle_key() function:
case KEY_UP:
case ALT ('\t'):
/* select previous link */
new_item = select_prev_link (startpoint, selected_item);
The 'startpoint' variable should be a pointer to the first byte
displayed in the Help window. But here it has a wrong value - that's
the problem. That's why select_prev_link() cannot find the link and
returns NULL, and the selection moves to the first link in the window.
I tried to find out what's wrong with the 'startpoint' variable.
I came to the conclusion that 'startpoint' is used here erroneously
instead of 'currentpoint' variable.
I am not convinced of that yet - see below. It's more likely
that the navigation code messes the value of 'startpoint'.
'currentpoint' always contains a pointer to the first byte displayed,
and it should be used here. And by the way, 'startpoint' variable
seems to be totally useless.
This is not true - 'currentpoint' points to the first byte of
the currently disaplyed help contents, while 'startpoint'
points to the start of the current link/topic. 'startpoint'
gets messed after one returns back from following a link.
So in my patch I replaced 'startpoint' with 'currentpoint' and
removed the 'startpoint' variable completely.
I won't apply this patch yet. I want to investigate further.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] mc crashes when temporary directory cannot be created
On Wed, 29 Nov 2006, Leonard den Ottolander wrote: 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? There is an even simpler cure. In mc_tmpdir() when executing the fallback code pass an absolute path to mc_mkstemps(). This will prevent the loop. However I am not yet conviced that this is the best solution. I am still investigating. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key
Hello Grigory, On Fri, 1 Dec 2006, Grigory Trenin wrote: Pavel Tsekov wrote: I won't apply this patch yet. I want to investigate further. Oh, now I see that I had hurried over to make that patch. I'll check everything and make another one. Without haste. The problem is that the structure which stores the history of the links followed stores only the pointer to the start of the node and doesn't store a pointer to the start of the currently displayed area of a node. When following a link MC does this: history_ptr = (history_ptr+1) % HISTORY_SIZE; history [history_ptr].page = currentpoint; history [history_ptr].link = selected_item; currentpoint = startpoint = help_follow_link (...); The start of the node in the history is erronously set to 'currentpoint'. Then when going back to the previous node via the left key the following code is executed via prev_node_cmd(): currentpoint = startpoint = history [history_ptr].page; selected_item = history [history_ptr].link; This leads to incorrectly setting 'startpoint' to the previously recorded value of 'currentpoint' which is wrong. I think the correct solution would be to keep both 'startpoint' and 'currentpoint' in the history but I am open to suggestions. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: find in viewer
Hello, On Fri, 8 Dec 2006, Nerijus Baliunas wrote: On Thu, 2 Nov 2006 09:51:58 +0200 (EET) Pavel Tsekov [EMAIL PROTECTED] wrote: could this patch please be committed to cvs (I am attaching it for your convenience)? BTW, how this patch works when two mc are running? If I search in 1st mc, then in 2nd mc, and then again in 1st mc, what will I get - last text from 1st or 2nd? I'd prefer from 1st, i.e. different mc sessions to be independent. This patch is not as good. Something else should be used. Reverting the original code that broke this feature might be better option for now. I'll try to do something about it till the weekend. Can this code please be reverted? On Thu, 18 May 2006 17:42:45 +0300 (EEST) Pavel Tsekov [EMAIL PROTECTED] wrote: The following commit broke it: http://cvs.savannah.gnu.org/viewcvs/mc/mc/src/view.c?sortby=dater2=1.336r1=1.335diff_format=u That change was done by rillig. Roland, could you please do it? The original problem description: Find in viewer does not remember its last search string: F3, F7, enter some text, Enter, F10. F3, F7 - search string field is empty. It used to remember earlier, and it doesn't happen with editor (editor remembers search string). I have a patch for this but I am a bit busy right now - moved to a new job. So if you wait a bit... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18476] Slow data transfer with FISH
Follow-up Comment #2, bug #18476 (project mc): Andrei, please, use the savannah bug reporting feature to comment on this issue. = On Monday 11 December 2006 00:22, you wrote: Follow-up Comment #1, bug #18476 (project mc): Can you provide the output of 'mc -V' ? Did you compile MC from sources or you installed a binary package ? If you compiled it yourself where did you get the source from ? I installed from FreeBSD ports. GNU Midnight Commander 4.6.1 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, smbfs With builtin Editor Using included S-Lang library with termcap database With subshell support as default With support for background operations With mouse support on xterm With internationalization support With multiple codepages support ___ Reply to this item at: http://savannah.gnu.org/bugs/?18476 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18476] Slow data transfer with FISH
Update of bug #18476 (project mc): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: The FreeBSD binary package is based on the original MC 4.6.1 tarball, which is quite old now, and some patches. The slow ssh transfer issue which you reported is fixed in CVS using a patch from Dmitry Butskoy. You can read the following discussion to find out more: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186456 So either point the FreeBSD mc maintainer to this discussion, so that he/she can add the patch to the set of patches applied to the FreeBSD package or built MC yourself from CVS or a snapshot tarball. You can get the latest snapshot tarball from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ ___ Reply to this item at: http://savannah.gnu.org/bugs/?18476 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key
Hello Grigory, On Mon, 11 Dec 2006, Grigory Trenin wrote: Pavel Tsekov wrote: I am not convinced that this patch is better than your first one. Its basically the same and removes a valid check - it doesn't fix the issue. It does fix the _original_ issue. And that one you are talking about is quite a different thing (see below). It isn't related to the original issue. Anyway, saving/restoring 'startpoint' in history won't fix it either. Try the following: COLS = 126 LINES = 60 1) F1 (Help) 2) Select contents and hit Enter 3) Press Page Down You should end up on Executing operating systems commands 4) Press Up You should notice that the marker doesn't select the previous link as it should. Why do you expect it? My mistake. Sorry. I'll review the patch more carefully. You are not annoying me - I just want to make sure that a given fix doesn't introduce new issues. In this case I was fooled. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc, ftp and filmview
BHello, On Thu, 14 Dec 2006, Admiral wrote: Halo, I am from belarus, i know English not so good. My problem in Russian language here: http://linuxforum.ru/index.php?showtopic=30151 Now, I try to write in English. In our local homenet we have ftp-server. There are many video-files in it. When I write mplayer ftp://ftp.server.local/films/verygoodfilm.avi; it start to play film immediately. But when I connect to ftp from mc and twice press to left button of mouse, mc previously download film completely, and then starts mplayer for playing movie. This is very bad, because films have big sizes and they are downloads very long time. How can I change it? You cannot. This is by design. If you want to stream the movies just use mplayer passing it the url. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc, ftp and filmview (fwd)
Hello, Please, keep the discussion on the list. Unfortunately, there is no such shortcut. -- Forwarded message -- Date: Fri, 15 Dec 2006 08:08:00 +0200 From: Admiral [EMAIL PROTECTED] To: Pavel Tsekov [EMAIL PROTECTED] Subject: Re: mc, ftp and filmview ? ? ?? 14 ??? 2006 15:53 ?? : BHello, On Thu, 14 Dec 2006, Admiral wrote: Halo, I am from belarus, i know English not so good. My problem in Russian language here: http://linuxforum.ru/index.php?showtopic=30151 Now, I try to write in English. In our local homenet we have ftp-server. There are many video-files in it. When I write mplayer ftp://ftp.server.local/films/verygoodfilm.avi; it start to play film immediately. But when I connect to ftp from mc and twice press to left button of mouse, mc previously download film completely, and then starts mplayer for playing movie. This is very bad, because films have big sizes and they are downloads very long time. How can I change it? You cannot. This is by design. If you want to stream the movies just use mplayer passing it the url. OK, but can you tell me a hotkey in mc to copy a full address of file in command line?___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc, ftp and filmview (fwd)
Hello Grigory, On Fri, 15 Dec 2006, Grigory Trenin wrote: OK, but can you tell me a hotkey in mc to copy a full address of file in command line? Try Ctrl+Shift+Enter. It may not work on some terminals, but it works for me. It will copy the full pathname to the command line, eg: /#ftp:ftp.server.local/films/verygoodfilm.avi However, you have to edit it a bit (replace /#ftp to ftp://) so that mplayer could understant it. Unfortunately, this may not always help since the path printed here may not be the real path or it may be unaccessible due to specific ftp server setup. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Prevent jumping beyond file end in the viewer
Hello Andrzej, On Wed, 20 Dec 2006, andrzej zaborowski wrote: in the hex viewer the GoTo (F5) command allows you to jump beyond end of file and even to view or edit data there. This is because the address given by user is not checked for correctness anywhere. Eventually, in src/view.c:view_file_load_data, the address is passed to lseek() whose return value is checked, but it turns out lseek'ing beyond end of file is legal and not an error. This immediately results in Bad Things (tm) like at the return from view_file_load_data the ds_file_datalen is actually negative. Attached diff fixes this. Thanks for your bugreport! I won't apply your patch though but a slightly modified one. I won't the viewer to display a warning box, reading something like Invalid offset or something, instead of just doing nothing. I'll let you know when I commit the patch. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] corrupted free inodes list
Hello Mikulas, On Wed, 20 Dec 2006, Mikulas Patocka wrote: I've found on three machines (I wonder that no one noticed it so far) that mc displays incorrect information on inode count, for example: Which version of MC are you using ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] corrupted free inodes list
On Wed, 20 Dec 2006, Pavel Tsekov wrote: Hello Mikulas, On Wed, 20 Dec 2006, Mikulas Patocka wrote: I've found on three machines (I wonder that no one noticed it so far) that mc displays incorrect information on inode count, for example: Which version of MC are you using ? Please, ignore the last message. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] corrupted free inodes list
Hello Mikulas, On Wed, 20 Dec 2006, Mikulas Patocka wrote: Hello Mikulas, On Wed, 20 Dec 2006, Mikulas Patocka wrote: I've found on three machines (I wonder that no one noticed it so far) that mc displays incorrect information on inode count, for example: Which version of MC are you using ? Stock 4.6.1 --- but I looked to CVS at http://cvs.savannah.gnu.org/viewcvs/mc/mc/ and it has int values in struct my_statfs too. Yes. I'll deal with that issue and let you know when I am ready. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] corrupted free inodes list
On Fri, 22 Dec 2006, Thomas Dickey wrote: On Fri, 22 Dec 2006, Leonard den Ottolander wrote: 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. It's likely to be slower, but if you don't exceed the precision of the mantissa, you won't lose information. The general reader, taking into account the comment about discrete is likely to assume that you meant information would be lost. Since that's not the case (for the assumed 48 bits), it's worth clarifying the comment. I am working to get this fixed. I plan to use code from coreutils's df to calculate the percent. I also resurrected the files fsusage.[ch] where originally the get_fs_usage() function resided. fsusage.[ch] come from gnulib/coreutils/filutils and its maintainers had switched to uintmax_t to collect the disk usage statistic for a long time now. I'll let you know when I am done. If someone is willing to help take a look at show_dev() in coreutils's source code. I am also wondering whether we won't to import human.[ch] from gnulib. IMO, it makes sense, but still this code does bit more than what we need but maybe in the long term its worth to rely on a known good and supported code instead of a homebrew solution. Please, let me know what do you think. Thanks! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight commander patches
Hello Sergey, 000-mc-4.6.1-fers.patch - MC already offers a find Recursively checkbox in the Find File dialog 001-mc-4.6.1-fh.patch - This patch (or variation of it) has been posted to the list several times. You might want to search the mailing list archives as to why it has been rejected. 003-mc-4.6.1-svp.patch - The viewer already supports saving the file position. You can enable it by setting mcview_remember_file_position to 1. I'll take a look at the clock patch and the Find first entry patch. Thanks! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Menu and extension file items
On Tue, 26 Dec 2006, Ruslan Fedyarov wrote: Hi dear MC developers, Thank you for your lightning fast wonderful program! I have a proposal to add the following stuff to standard menus: I think you should add those to .mc.menu or ~/.mc/mc.menu. Different users have different preferences that's why the user menu is user configurable trough the files above. I'd also appreciate having simple automount like in Krusader. It looks in /etc/fstab for directory queried and mounts one that match. Automount daemon works poor on my system. I don't know whether this is useful or not - I'll let others comment. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight commander patches
Hello Sergey, On Tue, 26 Dec 2006, Pavel Tsekov wrote: 000-mc-4.6.1-fers.patch - MC already offers a find Recursively checkbox in the Find File dialog According to the patch description this patch does the following: [...] Add checkboxes Find first entry and Recursive search in MC find dialog [...] First of all the text Find first entry is misleading. At first I thought that the idea was that it will match the first file given a pattern and will stop. When I looked at the patch I saw that what you meant is that turning on this option will stop the scan of the file contents once a match is found. I hope someone from the other developers on this list will help with naming this option properly. Next, I noticed that with your patch the scan will not really stop after a match is found - the code will keep reading the file till his end. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Prevent jumping beyond file end in the viewer
Hello Andrzej, On Wed, 2006-12-20 at 13:50, Pavel Tsekov wrote: On Wed, 20 Dec 2006, andrzej zaborowski wrote: in the hex viewer the GoTo (F5) command allows you to jump beyond end of file and even to view or edit data there. This is because the address given by user is not checked for correctness anywhere. Eventually, in src/view.c:view_file_load_data, the address is passed to lseek() whose return value is checked, but it turns out lseek'ing beyond end of file is legal and not an error. This immediately results in Bad Things (tm) like at the return from view_file_load_data the ds_file_datalen is actually negative. Attached diff fixes this. Thanks for your bugreport! I won't apply your patch though but a slightly modified one. I won't the viewer to display a warning box, reading something like Invalid offset or something, instead of just doing nothing. I'll let you know when I commit the patch. I've commited a slightly modified version of your patch - view_file_load_data() doesn't trash the buffer contents if an invalid offset is specified. I think it's better this way but it might changed in the future. I also added a dialog box to display a warning message if an invalid offset was specified. Thanks! ___ 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 Thu, 2006-11-30 at 20:04, Pavel Tsekov wrote:
On Wed, 29 Nov 2006, Leonard den Ottolander wrote:
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?
There is an even simpler cure. In mc_tmpdir() when executing
the fallback code pass an absolute path to mc_mkstemps().
This will prevent the loop. However I am not yet conviced
that this is the best solution. I am still investigating.
I am attaching a patch which passes an absolute path to mc_mkstemps()
when invoked from mc_tmpdir(). What do you think about this fix ?
I may add a comment why it is necessary to call mc_mkstemps() with
an absolute path. By the way I think we should add a check whether
the environment variable TMPDIR contains an absolute path. Anyway, I'll
leave this for another patch.
Index: src/utilunix.c
===
RCS file: /sources/mc/mc/src/utilunix.c,v
retrieving revision 1.88
diff -u -p -r1.88 utilunix.c
--- src/utilunix.c 27 Jul 2005 15:03:25 - 1.88
+++ src/utilunix.c 30 Dec 2006 18:44:22 -
@@ -280,19 +280,18 @@ mc_tmpdir (void)
}
}
-if (!error) {
- tmpdir = buffer;
-} else {
+if (error != NULL) {
int test_fd;
- char *test_fn;
+ char *test_fn, *fallback_prefix;
int fallback_ok = 0;
if (*error)
fprintf (stderr, error, buffer);
/* Test if sys_tmp is suitable for temporary files */
- tmpdir = sys_tmp;
- test_fd = mc_mkstemps (test_fn, mctest, NULL);
+ fallback_prefix = g_strdup_printf (%s/mctest, sys_tmp);
+ test_fd = mc_mkstemps (test_fn, fallback_prefix, NULL);
+ g_free (fallback_prefix);
if (test_fd != -1) {
close (test_fd);
test_fd = open (test_fn, O_RDONLY);
@@ -306,16 +305,19 @@ mc_tmpdir (void)
if (fallback_ok) {
fprintf (stderr, _(Temporary files will be created in %s\n),
sys_tmp);
+ g_snprintf (buffer, sizeof (buffer), %s, sys_tmp);
error = NULL;
} else {
fprintf (stderr, _(Temporary files will not be created\n));
- tmpdir = /dev/null/;
+ g_snprintf (buffer, sizeof (buffer), %s, /dev/null/);
}
fprintf (stderr, %s\n, _(Press any key to continue...));
getc (stdin);
}
+tmpdir = buffer;
+
if (!error)
mc_setenv (MC_TMPDIR, tmpdir, 1);
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17220] mc -a (stickchars) is gone
Update of bug #17220 (project mc): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #5: Closing as INVALID. Either file this report in RedHat's bugzilla or reopen it here if there is strong evidence that this bug is not caused by a Fedora patch/lib. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17220 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key
Hello Grigory, On Mon, 2006-12-04 at 19:45, Grigory Trenin wrote: Pavel Tsekov wrote: I think the correct solution would be to keep both 'startpoint' and 'currentpoint' in the history but I am open to suggestions. Yes, I thought about it too. This is a good and safe fix. But I have a suggestion. Actually, 'startpoint' is used only once at line 315 of help.c: p = current_link - 1; if (p = start) return 0; p = search_char_node (p, CHAR_LINK_START, -1); return p; Here 'current_link' is the pointer to the currently selected (highlighted) link, and 'start' == 'startpoint'. Since there can be no situation when currently selected link is outside of the current topic, (p = start) expression becomes true only in one rare case - when the first text in the node is a link, for example: ^D[Topic name]^ASome link^BSome link^C In that case 'p' will point to ']' character, and 'start_point' will point to ^A, so (p = start) condition will be true. But this check for (p = start) condition is not really necessary, because search_char_node() will not search beyond the topic boundaries, it will stop at ^D character and return NULL. So, if that check and the 'startpoint' variable itself are not really necessary and can be eliminated, why should we mess with saving/restoring 'startpoint' in the history? Please look at a new patch - what do you think? There I removed 'startpoint' as well as the first argument of select_prev_link() function. And after calling it there is no sense to check if (selected_item = last_shown) - this will never happen, so I removed it also. Ok. I think your arguments are reasonable. If the help viewer code was better organized I'd probably have insisted on keeping the variable holding the start of the node. However, I think that currently 'startpoint' brings more confusion than benefit, so I've applied your patch. Thanks! ___ 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 = Need Info Open/Closed: Closed = Open ___ 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: [bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !
Hello Egmont, And of course you're right! :) The strange thing is that your comment doesn't show in the comments for bug # 3836 ?!. On Tue, 2 Jan 2007, Egmont Koblinger wrote: Follow-up Comment #5, bug #3836 (project mc): Some time ago dpkg had a bug: when it removed a package that contained a symlink to /dev/null, it chmod'ed /dev/null to 000. The problem was that it did a chmod() instead of lchmod(), or stat() instead of lstat() or something like that on the file to be removed. Obviously if mc changed /dev/null to 600 for everyone, we would all know about it and it would be already fixed. On the other hand I have no reason to doubt the reporter. So I guess that the bug might be that mc (or maybe its wrapper script) chmod's something to 600, and this something (a temp file maybe) happens to be a symlink to /dev/null on the reporter's system due to some special setup or env var or special wrapper script or something like that... ___ 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 ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] mc crashes when temporary directory cannot be created
Hello, On Tue, 2 Jan 2007, Jindrich Novy wrote: On Sat, 2006-12-30 at 20:51 +0200, Pavel Tsekov wrote: There is an even simpler cure. In mc_tmpdir() when executing the fallback code pass an absolute path to mc_mkstemps(). This will prevent the loop. However I am not yet conviced that this is the best solution. I am still investigating. I am attaching a patch which passes an absolute path to mc_mkstemps() when invoked from mc_tmpdir(). What do you think about this fix ? I may add a comment why it is necessary to call mc_mkstemps() with an absolute path. By the way I think we should add a check whether the environment variable TMPDIR contains an absolute path. Anyway, I'll leave this for another patch. Thanks for the patch. Do you plan to convert the relative paths to absolute ones when detected? I think TMPDIR should be ignored in this case. What's your opinion ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] mc crashes when temporary directory cannot be created
Hello,
On Tue, 2 Jan 2007, Jindrich Novy wrote:
On Tue, 2007-01-02 at 16:28 +0200, Pavel Tsekov wrote:
On Tue, 2 Jan 2007, Jindrich Novy wrote:
On Sat, 2006-12-30 at 20:51 +0200, Pavel Tsekov wrote:
There is an even simpler cure. In mc_tmpdir() when executing
the fallback code pass an absolute path to mc_mkstemps().
This will prevent the loop. However I am not yet conviced
that this is the best solution. I am still investigating.
I am attaching a patch which passes an absolute path to mc_mkstemps()
when invoked from mc_tmpdir(). What do you think about this fix ?
I may add a comment why it is necessary to call mc_mkstemps() with
an absolute path. By the way I think we should add a check whether
the environment variable TMPDIR contains an absolute path. Anyway, I'll
leave this for another patch.
Thanks for the patch. Do you plan to convert the relative paths to
absolute ones when detected?
I think TMPDIR should be ignored in this case. What's your opinion ?
So some hardcoded value such as /tmp will then be assumed in case of
relative path in TMPDIR?
Yep. It already is:
sys_tmp = getenv (TMPDIR);
if (!sys_tmp) {
sys_tmp = TMPDIR_DEFAULT;
}
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] mc crashes when temporary directory cannot be created
On Tue, 2 Jan 2007, Jindrich Novy wrote: On Tue, 2007-01-02 at 16:28 +0200, Pavel Tsekov wrote: On Tue, 2 Jan 2007, Jindrich Novy wrote: On Sat, 2006-12-30 at 20:51 +0200, Pavel Tsekov wrote: There is an even simpler cure. In mc_tmpdir() when executing the fallback code pass an absolute path to mc_mkstemps(). This will prevent the loop. However I am not yet conviced that this is the best solution. I am still investigating. I am attaching a patch which passes an absolute path to mc_mkstemps() when invoked from mc_tmpdir(). What do you think about this fix ? I may add a comment why it is necessary to call mc_mkstemps() with an absolute path. By the way I think we should add a check whether the environment variable TMPDIR contains an absolute path. Anyway, I'll leave this for another patch. Thanks for the patch. Do you plan to convert the relative paths to absolute ones when detected? I think TMPDIR should be ignored in this case. What's your opinion ? So some hardcoded value such as /tmp will then be assumed in case of relative path in TMPDIR? Btw. does it make sense to use relative TMPDIR ?! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] mc crashes when temporary directory cannot be created
On Tue, 2007-01-02 at 16:53, Jindrich Novy wrote:
I am attaching a patch which passes an absolute path to mc_mkstemps()
when invoked from mc_tmpdir(). What do you think about this fix ?
I may add a comment why it is necessary to call mc_mkstemps() with
an absolute path. By the way I think we should add a check whether
the environment variable TMPDIR contains an absolute path. Anyway, I'll
leave this for another patch.
Thanks for the patch. Do you plan to convert the relative paths to
absolute ones when detected?
I think TMPDIR should be ignored in this case. What's your opinion ?
So some hardcoded value such as /tmp will then be assumed in case of
relative path in TMPDIR?
Yep. It already is:
sys_tmp = getenv (TMPDIR);
if (!sys_tmp) {
sys_tmp = TMPDIR_DEFAULT;
}
It sounds good for me then ;-)
The patch is in CVS now. I'll add a check for TMPDIR being an absolute
path later today.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Please, do not post to savannah bug database
Hello, The savannah bug database is currently experiencing some problems and bug comments are lost. Please, do not post until further notice. Thanks! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Hello Grigory, On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: Here are 3 patches to the mouse issues in the Help Viewer. [...] 3) mouse-linkfollow.patch When following a link with a mouse, an extra '\n' is insterted at the top of the window (just follow any link with a keyboard, then return back, and follow the same link with a mouse, and you should see the difference). [...] How about fixing help_follow_link() instead ? IMO, this would be a proper fix if we agree that the leading '\n' is not desired. The help format documentation says: The hypertext file is a file that may have one or more nodes. Each node ends with a ^D character and starts with a bracket, then the name of the node and then a closing bracket. I don't see anything about the newline being part of the node header and that it needs to be stripped. However, as you noted above if the keyboard is used to follow a link the newline is stripped. So, IMO, either the documentation is buggy and we have to fix it and fix help_follow_link() too or the key handling code is wrong to assume that it has to move beyond the newline. Any thoughts ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: 2) mouse-offbytwo.patch Last two lines of the help window (the bottom line and a frame) are not mouse-clickable. So the user will not be able to follow a link with a mouse, if it is situated at the bottom line. And the frame needs to be clickable because it serves a special purpose - page scrolling. This is patch is OK, but there are still problems. See this: create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4, ^^ HELP_WINDOW_WIDTH already is large enough to hold the dialog frame. As a resylt if you try to click on the right hand side of the dialog you dont get any movement. I'd like to fix this before applying your patch so I can commit both fixes. Unfortunately removing the + 4 part is not enough to properly fix the problem. It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. I'll investigate and let you know what have I found. In the meantime if you want to help me - you are welcome :) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 22:43, Grigory Trenin wrote: Pavel Tsekov wrote: How about fixing help_follow_link() instead ? IMO, this would be a proper fix if we agree that the leading '\n' is not desired. Good point! Certainly, this would be better. The help format documentation says: The hypertext file is a file that may have one or more nodes. Each node ends with a ^D character and starts with a bracket, then the name of the node and then a closing bracket. I don't see anything about the newline being part of the node header and that it needs to be stripped. However, as you noted above if the keyboard is used to follow a link the newline is stripped. So, IMO, either the documentation is buggy and we have to fix it and fix help_follow_link() too or the key handling code is wrong to assume that it has to move beyond the newline. Any thoughts ? It is man2hlp.c who always puts newline after the node header: fprintf (f_out, \004[Contents]\n); ... fprintf (f_out, %c[%s], CHAR_NODE_END, buffer); col++; newline (); Yep. Besides, newlines are also present in the template - xnc.hlp file. It is interesting, however, that move_backward2(), which is called when the up key is pressed, assumes '\n' as a part of the node header, but move_to_top(), which is called when the home key is pressed - doesn't. As for me, I don't like that leading '\n', but it is probably a matter of taste. IMHO it is better to fix help_follow_link(), move_to_top(), and documentation... I don't like it either :) But I'd like to hear from the other people on this list, if possible, before doing anything. But I remember (it was 2 months ago, I guess) you suggested to rip line wrapping code out of man2hlp and to put it in the Help Viewer... If you still plan to do it, may be it would be better to patch man2hlp.c also not to insert '\n' after the node header... Hmm. I don't really understand why the '\n' is necessary - and since the code is quite old perhaps noone remebers anymore. I'll play with the code a bit and see if I be able to determine whether the newline is of any importance. I'll see if the changelogs will be of any help too. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
No MC snapshot since 2006-12-28
Would you check why the snapshot is not being generated ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: 1) mouse-rightbutton.patch Returning to a previous node by pressing right mouse button doesn't work in xterm. It works only in Linux console with GPM. The problem is that help_event() catches only GPM_UP event, and it seems that xterm doesn't report which mouse button was released. Handling GPM_DOWN instead of GPM_UP will fix it. I had this idea now. How about fixing the code that captures mouse events from xterm instead ? I.e. when it receives a mouse down event it will record which key was pressed and it will copy this information to the mouse up event ? I'm CC-ing to the xterm developer just in case he can give some insight. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: No MC snapshot since 2006-12-28
On Thu, 2007-01-04 at 21:07, Pavel Roskin wrote: On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote: Would you check why the snapshot is not being generated ? No problems this time. I run the snapshot generator manually from time to time. The new snapshot is available now. I see. I thought the snapshot was generated manually. At least it seemed to me that new versions appear after changes were commited :) Perhaps the process can be automated ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Thu, 2007-01-04 at 22:33, Grigory Trenin wrote: Pavel Tsekov wrote: I had this idea now. How about fixing the code that captures mouse events from xterm instead ? I.e. when it receives a mouse down event it will record which key was pressed and it will copy this information to the mouse up event ? This will be not always reliable. Suppose such situation: a user presses left mouse button, then (without releasing it) presses right mouse button, and finally, he releases one of these buttons. How do we know which button (left or right) was released? Well, we don't :) But who will do this anyway ? I mean it's pointless :) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: No MC snapshot since 2006-12-28
On Fri, 2007-01-05 at 01:27, Pavel Roskin wrote: On Thu, 2007-01-04 at 23:07 +0200, Pavel Tsekov wrote: On Thu, 2007-01-04 at 21:07, Pavel Roskin wrote: On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote: Would you check why the snapshot is not being generated ? No problems this time. I run the snapshot generator manually from time to time. The new snapshot is available now. I see. I thought the snapshot was generated manually. At least it seemed to me that new versions appear after changes were commited :) Perhaps the process can be automated ? The script will need to find out if there are any updates in CVS. We don't want to post a snapshot without actual changes in CVS. Unfortunately, there is no single commit ID in CVS, so I'll need to implement an algorithm to calculate it (I think it could be SHA1 of the sorted list of all files with revisions). Isn't it possible to use the CVS output to see if there were updated files ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18689] Config checkboxes not acting on mouse click
Update of bug #18689 (project mc): Status:None = Confirmed ___ Follow-up Comment #1: Oh, well. The mouse event is directed to the groupbox (the frame holding other widgets inside it). The bad thing is that the groupbox is rather simplistic widget and it doesn't know anything about the widgets that are displayed inside it :( IMO, the real solution to this problem should involve teaching the groupbox that it holds other widgets (i.e. making it a real container widget). A simplistic solution would be to skip groupboxes when dispatching mouse events. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18689 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18695] tab completion vs. spaces and escaping
Follow-up Comment #1, bug #18695 (project mc): Sounds familiar... http://savannah.gnu.org/bugs/?16176 ___ Reply to this item at: http://savannah.gnu.org/bugs/?18695 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Fri, 2007-01-05 at 02:32, Grigory Trenin wrote: Pavel Tsekov wrote: On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: This is patch is OK, but there are still problems. See this: create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4, ^^ HELP_WINDOW_WIDTH already is large enough to hold the dialog frame. As a resylt if you try to click on the right hand side of the dialog you dont get any movement. I'd like to fix this before applying your patch so I can commit both fixes. Unfortunately removing the + 4 part is not enough to properly fix the problem. It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. I'll investigate and let you know what have I found. In the meantime if you want to help me - you are welcome :) So, there are two ways to get rid of that empty space on the right: 1) Shrink the window from 63 chars to HELP_TEXT_WIDTH (58 chars). This will cause some difficulties due to the usage of preformatted text - need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. 2) Expand HELP_TEXT_WIDTH to the effective window width (63 chars). IMHO this is better. Besides, I think it would be nice to leave a margin in one column between a text and a frame. Should I try and do it? What do you think? Implementing either solution would not remove the necessity of this: [...] need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. [...] To fix this there should be no preformatted pages involved, IMO. But I may be wrong. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Sat, 6 Jan 2007, Grigory Trenin wrote: Pavel Tsekov wrote: Implementing either solution would not remove the necessity of this: [...] need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. [...] To fix this there should be no preformatted pages involved, IMO. But I may be wrong. Well, sometimes preformatting is useful. Of course, it shouldn't be used for regular text, as it is used now. But in some nodes config files samples (like mc.menu) are given, and it is necessary to preserve indents and avoid line wraping for them. Besides, man2hlp handles a limited number of groff commands, it doesn't handle .ce command for example, so it is not possible to center lines with man2hlp. It is done by preformatting now. If we decide to eliminate all preformatting, it is necessary to patch man2hlp to center lines. I don't know whether the result will cover the efforts. May be it is easier just to leave that space on the right as is, and make it mouse-clickable? Well, we can go with the simple solution for now - but it should be documented somewhere to prevent further confusion. As to whether it is worth the effort - think about this: Me and you together spent a considerable amount of time on a simple issue - was it worth it ? I think making the things right will allow the developer to spend his time on more pressing issues. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 23:03, Pavel Tsekov wrote: On Wed, 2007-01-03 at 22:43, Grigory Trenin wrote: Pavel Tsekov wrote: How about fixing help_follow_link() instead ? IMO, this would be a proper fix if we agree that the leading '\n' is not desired. Good point! Certainly, this would be better. The help format documentation says: The hypertext file is a file that may have one or more nodes. Each node ends with a ^D character and starts with a bracket, then the name of the node and then a closing bracket. I don't see anything about the newline being part of the node header and that it needs to be stripped. However, as you noted above if the keyboard is used to follow a link the newline is stripped. So, IMO, either the documentation is buggy and we have to fix it and fix help_follow_link() too or the key handling code is wrong to assume that it has to move beyond the newline. Any thoughts ? It is man2hlp.c who always puts newline after the node header: fprintf (f_out, \004[Contents]\n); ... fprintf (f_out, %c[%s], CHAR_NODE_END, buffer); col++; newline (); Yep. Besides, newlines are also present in the template - xnc.hlp file. It is interesting, however, that move_backward2(), which is called when the up key is pressed, assumes '\n' as a part of the node header, but move_to_top(), which is called when the home key is pressed - doesn't. As for me, I don't like that leading '\n', but it is probably a matter of taste. IMHO it is better to fix help_follow_link(), move_to_top(), and documentation... I don't like it either :) But I'd like to hear from the other people on this list, if possible, before doing anything. If anyone has something to add to this issue it's about time. Otherwise I'll move to fixing this issue one way or the other. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16029] MC doesn't open if network gateway inaccessible.
Update of bug #16029 (project mc): Status: Need Info = None ___ Follow-up Comment #6: The problem is due to the outdated samba library included with MC. You can find out more here: http://mail.gnome.org/archives/mc/2006-September/msg00047.html We actually don't need info any more since we know what's the cause of the hang - changing the status to None. ___ 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
Re: [PATCH] Help Viewer - mouse issues
On Tue, 2007-01-09 at 19:08, Grigory Trenin wrote: Pavel Tsekov wrote: Well, we can go with the simple solution for now - but it should be documented somewhere to prevent further confusion. As to whether it is worth the effort - think about this: Me and you together spent a considerable amount of time on a simple issue - was it worth it ? I think making the things right will allow the developer to spend his time on more pressing issues. I am not quite satisfied with that simple solution too. What do you think if I convert xnc.hlp to mandoc format and patch man2hlp respectively? I think it will be sufficient to add to man2hlp support of these two troff commands: 1) '.ce' (to center lines) 2) '.ti' (temporary indent - to support right indention of the first line of the paragraph). Sound nice. Do you have a patch already ? :) Btw. after those changes do you think that xnc.hlp will still be necessary ? P.S. Your help is much appreciated! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18766] Not re-sorted at panel swap
Follow-up Comment #1, bug #18766 (project mc): Uhm, well.. It seems this behaviour is by design: [...] Tue Aug 29 14:33:16 1995 Jakub Jelinek * layout.c (swap_panels): Fixed. Now it should work fine and if there are both view_listings, then it just swappes their content (and not formats etc.), so that you may have one format in the left and a different one in the right panel and if you want to see some things that are in the left for a file on the right, you just C-u. [...] And also from the swap_panels() in layout.c: /* Change everything except format/sort/panel_name etc. */ As I understand it the idea is to have a super-fast way to view some file attributes which are not displayed in the other view but are displayed in the current panel view. I noticed that this function is not documented very well - IMO the documentation is not clear on what this command's purpose is :) ___ Reply to this item at: http://savannah.gnu.org/bugs/?18766 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18767] Panel sort order: fallback to name
Follow-up Comment #1, bug #18767 (project mc): I don't know if the Unsorted view make sense but I know that the GNU 'ls' has a -U option which is supposed to print unsorted entries. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18767 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18767] Panel sort order: fallback to name
Follow-up Comment #2, bug #18767 (project mc): Egmont, I've just verified that GNU ls does what you suggest in the situation described below. I'll apply a patch soon. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18767 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18767] Panel sort order: fallback to name
Follow-up Comment #3, bug #18767 (project mc): I've commited a patch: http://cvs.sv.gnu.org/viewcvs/mc/mc/src/dir.c?sortby=dater2=1.67r1=1.66diff_format=u ___ Reply to this item at: http://savannah.gnu.org/bugs/?18767 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18767] Panel sort order: fallback to name
Update of bug #18767 (project mc): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #5: Well, the guy who posted the bug report below seemed to use the Unsorted mode: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13549 Maybe, there are others too. As for myself - I never used it but still I don't mind it. However if you want to discuss the Unsorted mode, please, open a new bugreport. I am closing this one now. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18767 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: view like 'tail -f'
Hello, On Tue, 2007-01-16 at 00:18, [EMAIL PROTECTED] wrote: Suggestion: modify the internal viewer so that it can act like 'tail -f'. Would you mind entering your request in the bug database at savannah.gnu.org ? Thanks! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: calculate directory size
Hello, On Thu, 18 Jan 2007, [EMAIL PROTECTED] wrote: I have a suggestion again: calculation of directory size on pressing F3 and/or on marking directory, maybe as an option. Many file managers have this feature. I'd like to see it in Midnight Commander too. I don't mind entering my request in the bug database. This request is already in the bug database. See this for exmaple: http://savannah.gnu.org/bugs/?11951 Btw. I don't remember whether we had a discussion why F3 isn't appropriate. Comment #4 in the discussion above refers to F3 being using to invoket NC's viewer. While I do remember that F3 on a file invoked that viewer I don't NC handy to verify what it does when F3 is pressed on a directory. Anyway I happen to agree that if most of the NC-like file managers out there do this we should do it too. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Hello, On Wed, 2007-01-03 at 23:03, Pavel Tsekov wrote: Hmm. I don't really understand why the '\n' is necessary - and since the code is quite old perhaps noone remebers anymore. I'll play with the code a bit and see if I be able to determine whether the newline is of any importance. I'll see if the changelogs will be of any help too. Ok. I now understand why the newline after the header is necessary. It is there to faciliate the editor of the template file (xnc.hlp). Other than that the newline is really unnecessary. So, I'll keep it there, I'll document it in the node header format and apply a patch to make all help.c functions deal consistently with it. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18977] Case insensetive search in mc doesn't work
Follow-up Comment #1, bug #18977 (project mc): Please, read the link below - this is the expected behaviour: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351562 Anyway, I'll take a look at those patches. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18977 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow
Follow-up Comment #1, bug #18913 (project mc): I cannot reproduce this problem with a CVS version of MC. Are you using are self-built MC or a binary package which comes with some distribution ? The bug that you are experiencing may be due to the UTF-8 patches used by some distros. If that is the case it'd be best to file this bug report against your distro's bug database. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow
Update of bug #18913 (project mc): Category:None = Editor ___ Reply to this item at: http://savannah.gnu.org/bugs/?18913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow
Follow-up Comment #2, bug #18913 (project mc): Originally posted by Richard Blakie: I am using the original Red-Hat RPM release for Fedora Core 5 provided on their site. The release is mc-4.6.1a-35.fc5.i386.rpm Does this mean that if compiled with UTF-8, it could cause problems in ISO8859-1 ? I am not sure what options the package is compiled with but I will try and find out. I just tested on UBUNTU and it does not have this problem. Do you know of anything I could look at to know about what MC was compiled with ? Thanks in advance from Toronto, Canada ___ Reply to this item at: http://savannah.gnu.org/bugs/?18913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow
Update of bug #18913 (project mc): Operating System:GNU/Hurd = GNU/Linux ___ Follow-up Comment #3: Richard, Fedora's rpm comes with UTF-8 support built-in - no need to try and find out. I don't have Fedora installed right now so I cannot test and see what's wrong. I'll try to play with the Ubuntu MC package since I have Ubuntu installed on my laptop. Anyway, I think the output of the command 'locale' would be useful to reproduce the crash, so, please, post it here in this bug report. And then again - it might be worth to open a bug report in Fedora's bugzilla. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow
Follow-up Comment #4, bug #18913 (project mc): Originally posted by Richard Blakie: Hello Pavel, this is my 'locale' output: LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= I am investigating the redhat problem reports. I will let you know. But since the problem does not exist in the UBUNTU release, your guess is probably right : it has something to do with either 1-)the fedora MC release or 2-)the Fedora system configuration. Although my default is en_US.UTF-8, I often have to deal with french files for Quebec. So I can't change my system to all UTF-8. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow
Follow-up Comment #5, bug #18913 (project mc): Richard could you use the Post a Comment savannah's bug tracking facility instead of personally messaging me ? ___ Reply to this item at: http://savannah.gnu.org/bugs/?18913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow
Follow-up Comment #7, bug #18913 (project mc): Using MC from CVS i.e. (without the UTF-8 patch) I don't see the crash. So it really makes sense to move the discussion to Fedora's bug tracking facility and maybe post a link to this discussion there. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow
Update of bug #18913 (project mc): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #9: Ok. Closing as won't fix. If someone feels that this is really a bug in MC and not the UTF-8 patch, please, feel free to reopen. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18977] Case insensetive search in mc doesn't work
Follow-up Comment #2, bug #18977 (project mc): I took a look at the patch and it is pretty straightforward. However it is not what we want - it misuses the case Sensitive mark under the Content field - that flag is related to the data entered into the Content field and not the Filename field. I'll modify the dialog and adjust the code to do the right thing. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18977 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: view like 'tail -f'
Hello, On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote: Suggestion: modify the internal viewer so that it can act like 'tail -f'. Why do you think it is usefull to have this functionality ? What are its use cases ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: maybe a bug in copy files
Hello Lubomir, On Mon, 22 Jan 2007, Lubomir Grajciar wrote: When I try to copy file(s) with unchecked preserve atributes checkbox as regular user, copied files hasn't attributes based on my umask. My umask is: 0022 Copied file attributes: 600 When I try to create a new file (for example with shift-F4), it is created with right attributes (644). Thanks for noticing and reporting this! It is indeed a bug and it has been here for the last 5 years. For the curious - there is a thread with a subject of Problems with vfs / ftpfs started on 27 Feb 2002. As it can be seen the patch posted by Andrew calls chmod() on the target file only if preserve attributes is set. However, it has to be called in both cases since the destination file is created with mode 600 initially due to security concerns - more info can be found in file.c . I'll revert that patch. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: maybe a bug in copy files
Hello Egmont,
On Thu, 22 Feb 2007, Egmont Koblinger wrote:
Hi,
[...] As it can be
seen the patch posted by Andrew calls chmod() on the target
file only if preserve attributes is set. However, it has to
be called in both cases since the destination file is created
with mode 600 initially due to security concerns - more info
can be found in file.c .
I think this is overcomplicated... open() does not create the file with the
permission taken from its third argument, it masks it with umask. So
currently the file is not created with mode 600, but with mode (600
^umask).
What's wrong with the following simple solution?
When creating the file, pass the permissions of the old file to the open()
call. This way it will have no more permissions than the original file, and
no more permission than umask suggests.
When copying is finished, call chmod() only if preserve attributes is set.
/* Create the new regular file with small permissions initially,
do not create a security hole. FIXME: You have security hole
here, btw. Imagine copying to /tmp and symlink attack :-( */
while ((dest_desc = mc_open (dst_path, O_WRONLY | (ctx-do_append ?
O_APPEND : (O_CREAT | O_TRUNC)), 0600)) 0) {
I remember that there is a discussion somewhere on the mailing list
as to what this security concern is. I will try to dig it and see
whether it really makes sense to do it the way it currently is.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: maybe a bug in copy files
Hello, On Thu, 22 Feb 2007, Pavel Tsekov wrote: I remember that there is a discussion somewhere on the mailing list as to what this security concern is. I will try to dig it and see whether it really makes sense to do it the way it currently is. Here it is: http://mail.gnome.org/archives/mc-devel/2006-June/msg00063.html Shall we discuss how to create the file in a secure manner and avoid the call to mc_chmod() ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Request for discussion - how to make MC unicode capable
Hello, I'd like to initiate a discussion on how to make MC unicode deal with multibyte character sets. I'd like to hear from the developers of the UTF-8 patch and from the ncurses maintaner. Anyone else who can help with their expertise is also welcome. This has been a major drawback for quite some time and it needs to be addressed ASAP. Thanks! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: maybe a bug in copy files
Hello, On Mon, 26 Feb 2007, Egmont Koblinger wrote: On Thu, Feb 22, 2007 at 05:44:39PM +0200, Pavel Tsekov wrote: Here it is: http://mail.gnome.org/archives/mc-devel/2006-June/msg00063.html Shall we discuss how to create the file in a secure manner and avoid the call to mc_chmod() ? I think we're talking about two separate issues. One is how to safely create a file (without race condition) so that we really create _that_ file and not another one via a new symlink. The answer is O_EXCL. The other issue is how to create the file with the right permissions so that we don't leak information. I guess I proposed a cleaner solution for this than the current one. I can't see any correlation between these two issues. Ok. Maybe we are talking about different issues. What I was talking about was that the current code in MC requires the chmod() that i've ressurected. From what I understand you was talking that if we change the code we may avoid the chmod() call at the end. Is this right ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
