Re: [PATCH] Re: deb-support-without-dpkg.patch was Re: AMC patches ported to mc-2006-02-03-13.tar.gz
On Thu, 9 Mar 2006, Leonard den Ottolander wrote:
On Wed, 2006-03-08 at 17:50 +0200, Pavel Tsekov wrote:
2005 control.tar.gz
It appears ar is the app which uses 4 field dates that I was looking
for ;-s . Please try the following patch against vfs/extfs/uar. It
removes the fourth date field from the ls output.
The patch behaves well on Linux (with GNU tools), but not on Solaris for
example.
+ thisyear=$(date +%Y)
This should be changed to:
thisyear=`date +%Y`
Why is this necessary:
+ $XAR tv $1 | sed 's,^,-,;s, , 1 ,;s,/, ,' | sed -e
s/\(.\?\)\([0-2][0-9]\:[0-5][0-9] \)\(${thisyear} \)\(.*\)/\1\2\4/ | sed -e
s/\(.\?\)\([0-2][0-9]\:[0-5][0-9] \)\([0-2][0-9][0-9][0-9] \)\(.*\)/\1\3\4/
^^^
The \? is GNU extension and I don't really understand why that construct
is necessary (I am not a regex guru though) so can you explain ?
Since it is impossible to distinguish between 3 and 4 field dates and
the implementation of a separate path for 3 and 4 field dates is not
trivial the approach should always be to strip down 4 field dates to 3
fields.
I agree. Determining the date format could be achieved but it is not a
trivial task and I am not really sure that it is so important after all.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #13101] Moving/copying single files to FTP VFS
Follow-up Comment #12, bug #13101 (project mc): I'll wait till 21 March before commiting this patch. That's almost two weeks - I think this is enough time for other developers to comment. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13101 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Inconsistent behaviour of Options
Hi mc-devel, there are two types of dialogs in Options menu. The first type contains three buttons: Ok, Save, Cancel and the second only Ok and Cancel. There's a default action in the dialogs with only Ok and Cancel that Ok saves the configuration globally so that it's written to ini file just after finishing the dialog. If you try to configure with Options/Configuration... and Options/Layout... you see Ok, Save, Cancel. If you press either Ok or Save the settings are written to ini file so that the settings will be set again when new mc is launched and not only for the current session. The question is whether to fix the bug in the way that: 1. Ok sets the parameters only for the current session and won't touch the ini file. Save saves the configuration to ini file so that it's needed to add the Save button to the rest of the Options dialog entries to make it consistent. 2. Ok sets the parameters to ini file for all the dialogs, so that it's needed to remove Save button from the Layout and Configuration options to make it consistent. What's your opinion? Jindrich ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Comments on deb-support-without-dpkg.patch
Chan On Mon, 6 Feb 2006, Pavel Tsekov wrote: deb-support-without-dpkg.patch For systems withoput dpkg (almost any non-debian OS). It handles .deb files as regular .ar archives, as they are in reality. This would be nice addition. Only if we could avoid the 'O' option of gnu tar... Does anyone know of a way to avoid it ? In any case I think this patch is worth adding. This patch although useful has certain drawbacks and I don't think it is ready to replace the use of dpkg as-is. 1) To use the patch one has to install development tools (i.e. binutils). This is not a major problem but it is still annoying - especially for non-developers. 2) Open=%cd %p#uar differs in behaviour from Open=%cd %p#deb - in my opinion Open=%cd %p#deb is better. However, the deb script may be modified to use ar when it detects that dpgk is missing. I think this would be the best thing to do. 3) The View command is highly unportable. Are you willing to improve your patch ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Comments on deb-support-without-dpkg.patch
Hi, This patch although useful has certain drawbacks and I don't think it is ready to replace the use of dpkg as-is. i never thought so. 1) To use the patch one has to install development tools (i.e. binutils). This is not a major problem but it is still annoying - especially for non-developers. 2) Open=%cd %p#uar differs in behaviour from Open=%cd %p#deb - in my opinion Open=%cd %p#deb is better. However, the deb script may be modified to use ar when it detects that dpgk is missing. I think this would be the best thing to do. 3) The View command is highly unportable. Are you willing to improve your patch ? no, at least not in the near future. it works for me as-is, and i have no time and resources for testing and improving it for other systems. anyway of course it should only be used when dpkg is not available. in that case, it's still far more better than nothing... about the differences to dpkg - i've never seen the #deb thing working, as i dont have debian (or other dpkg-based distros) installed. A'rpi ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Comments on deb-support-without-dpkg.patch
On Thu, 9 Mar 2006, Arpi wrote: This patch although useful has certain drawbacks and I don't think it is ready to replace the use of dpkg as-is. i never thought so. 1) To use the patch one has to install development tools (i.e. binutils). This is not a major problem but it is still annoying - especially for non-developers. 2) Open=%cd %p#uar differs in behaviour from Open=%cd %p#deb - in my opinion Open=%cd %p#deb is better. However, the deb script may be modified to use ar when it detects that dpgk is missing. I think this would be the best thing to do. 3) The View command is highly unportable. Are you willing to improve your patch ? no, at least not in the near future. it works for me as-is, and i have no time and resources for testing and improving it for other systems. anyway of course it should only be used when dpkg is not available. in that case, it's still far more better than nothing... about the differences to dpkg - i've never seen the #deb thing working, as i dont have debian (or other dpkg-based distros) installed. dpkg is freely available for download. I never used it myself but I found it and tested the deb script as well as your patch. As you said above your patch is supposed to kick in if dpkg is not available... The way you implemented it uar is used all the time even if dpkg is present. I might try to implement 2 myself when I have more time - it doesn't seem to be too hard anyway. IMO, this patch is not ready for inclusion in MC. Still I don't think your work is in vain - I never knew that .deb files are just ordinary archives and it is possible to manipulate them trough ar. Based on this knowledge I will try to provide a better .deb handler . ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Comments on deb-support-without-dpkg.patch
Hi, dpkg is freely available for download. I never used it myself but I found it and tested the deb script as well as your patch. As you said above but i'm lazy... and i'm sitting on macosx, not linux... (dunno if dpkg is available for osx, maybe yes, but dunno) your patch is supposed to kick in if dpkg is not available... The way you implemented it uar is used all the time even if dpkg is present. i know. it as just a quick dirty hack, and a proof-of-concept that dpkg is not required to open/extract deb archives (just like cpio is enough for rpm files) I might try to implement 2 myself when I have more time - it doesn't seem to be too hard anyway. IMO, this patch is not ready for inclusion in MC. Still I don't think your work is in vain - I never knew that .deb files are just ordinary archives and it is possible to manipulate them trough ar. Based on this knowledge I will try to provide a better .deb handler . ok, thanks A'rpi ___ 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:None = Need Info ___ Follow-up Comment #2: I couldn't reproduce on FC3 with latest cvs version. Would you mind providing a strace of MC hanging ? You could do so by issuing the following command: strace -o /tmp/mc.strace /usr/bin/mc Replace /usr/bin/mc with the full path to the mc binary. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16029 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Inconsistent behaviour of Options
Hello Pavel, On Thu, 2006-03-09 at 15:14 +0200, Pavel Tsekov wrote: The question is whether to fix the bug in the way that: 1. Ok sets the parameters only for the current session and won't touch the ini file. Save saves the configuration to ini file so that it's needed to add the Save button to the rest of the Options dialog entries to make it consistent. 2. Ok sets the parameters to ini file for all the dialogs, so that it's needed to remove Save button from the Layout and Configuration options to make it consistent. What's your opinion? I think solution number 2 is better. After all we have Options - Save setup so the Save buttons are somewhat redundant. There is also the auto_save_setup option which saves the ini file on exit. I also prefer this solution as the implementation of the Save button is kind of strange because the Save button is handled by B_EXIT action in init_layout() and layout_cmd() and is rather useless in general ;-) Jindrich ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: deb-support-without-dpkg.patch was Re: AMC patches ported to mc-2006-02-03-13.tar.gz
Hi Pavel, On Thu, 2006-03-09 at 10:45 +0200, Pavel Tsekov wrote: thisyear=`date +%Y` I assumed the $(command) was portable. If not I need to restore the backticks in mc.wrapper.sh as well. The \? is GNU extension and I don't really understand why that construct is necessary (I am not a regex guru though) so can you explain ? The .* matches greedily, so a file name containing a time would be matched instead of the actual time. This is why I used the '?'. Is there a non GNU equivalent for a non greedy match? I'm no regex guru either, so input on how to do this better is appreciated. By the way, instead of a pipe the second expression should only be used if the first didn't match. The current construct strips the year of a file with a name that starts with a year and has a date in this year (i.e. 01:23 2006 2005 bla). I agree. Determining the date format could be achieved but it is not a trivial task and I am not really sure that it is so important after all. I'll document the fact that dates being passed to vfs_parse_ls_lga() need to be parsed back to 3 fields. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: deb-support-without-dpkg.patch was Re: AMC patches ported to mc-2006-02-03-13.tar.gz
Hi Pavel, On Thu, 2006-03-09 at 10:45 +0200, Pavel Tsekov wrote: The \? is GNU extension Is it? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Inconsistent behaviour of Options
Hi Jindrich, On Thu, 2006-03-09 at 13:48 +0100, Jindrich Novy wrote: 1. Ok sets the parameters only for the current session and won't touch the ini file. Ok is equivalent to save if auto save setup is set. If auto save setup is unset ok and save do differ in their behaviour. This actually *is* consistent. As I hardly change options I had sort of forgotten about the auto save behaviour and I'm afraid I might have confused you because of that :) . 2. Ok sets the parameters to ini file for all the dialogs, so that it's needed to remove Save button from the Layout and Configuration options to make it consistent. Actually I think we miss a save button in the confirmation dialog :-) . I assume the global save setup saves the settings for all these sections. I don't think we should drop the fine grained save buttons in the other dialogs. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Inconsistent behaviour of Options
Hello! On Thu, 2006-03-09 at 23:14 +0100, Leonard den Ottolander wrote: Hi Jindrich, On Thu, 2006-03-09 at 13:48 +0100, Jindrich Novy wrote: 1. Ok sets the parameters only for the current session and won't touch the ini file. Ok is equivalent to save if auto save setup is set. ... and if you exit from mc rather than e.g. close the xterm window. And if you don't have another mc running that would overwrite those settings if you exit from it properly. I think that auto save setup is something that cannot be implemented reliably in mc unless you make Ok work exactly like Save and save changes immediately. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Inconsistent behaviour of Options
Hello Pavel, On Thu, 2006-03-09 at 17:31 -0500, Pavel Roskin wrote: ... and if you exit from mc rather than e.g. close the xterm window. And if you don't have another mc running that would overwrite those settings if you exit from it properly. The latter would still be a problem with direct saves. And that auto save setup only works on normal programme termination should be obvious. I think that auto save setup is something that cannot be implemented reliably in mc unless you make Ok work exactly like Save and save changes immediately. But then the option auto save setup would be redundant... Unless you mean that the behaviour of Ok should be changed based on the current auto save setting. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Inconsistent behaviour of Options
On Thu, 2006-03-09 at 23:40 +0100, Leonard den Ottolander wrote: Hello Pavel, On Thu, 2006-03-09 at 17:31 -0500, Pavel Roskin wrote: ... and if you exit from mc rather than e.g. close the xterm window. And if you don't have another mc running that would overwrite those settings if you exit from it properly. The latter would still be a problem with direct saves. I don't understand which scenario you have in mind. If you mean saving settings from two mc instances, that would be a problem, but it's a counter-intuitive thing for users to do. And that auto save setup only works on normal programme termination should be obvious. Remember, users can be distracted, and they are generally assumed to have a short attention span. You cannot expect a user to remember to exit from mc correctly to save settings. There may be thousands of things between changing the configuration and ending mc, and some of them can kill mc, e.g. as X crash due to some other software, closing a wrong window, reboot due to urgent security upgrade etc. I actually find it more natural that once the dialog has been dismissed by any button, I don't have to remember to do anything. I'm accustomed to software that doesn't use my memory too much. Also, programs that save anything on exit try to protect against killing until that data has been saved. That's why SIGKILL is the last resort. mc doesn't do anything like that, as it would lose the unsaved configuration even on SIGHUP. I think that auto save setup is something that cannot be implemented reliably in mc unless you make Ok work exactly like Save and save changes immediately. But then the option auto save setup would be redundant... Unless you mean that the behaviour of Ok should be changed based on the current auto save setting. I think auto save setup is redundant, but I never had time to remove it. Besides, it would open a huge can of worms. Some users rely on auto save setup to have mc remember the last directories. Sure, such users have a different mental model of mc, they try not to kill mc, and I guess they run one copy of mc at most (so it's more a DOS/Norton Commander like model). Another group of users likes to edit configuration files manually. If mc defaults not to save the configuration, the configuration files are not created first time mc is run. Somebody would complain. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Inconsistent behaviour of Options
On Thu, Mar 09, 2006 at 05:31:27PM -0500, Pavel Roskin wrote: On Thu, 2006-03-09 at 23:14 +0100, Leonard den Ottolander wrote: On Thu, 2006-03-09 at 13:48 +0100, Jindrich Novy wrote: 1. Ok sets the parameters only for the current session and won't touch the ini file. Ok is equivalent to save if auto save setup is set. ... and if you exit from mc rather than e.g. close the xterm window. just closing xterm is generally a stupid idea. and forgetting it at session exit ... my wish for supporting xsmp still stands. And if you don't have another mc running that would overwrite those settings if you exit from it properly. KConfig rescans the config and merges the changes into the just read config on saving. i think it wouldn't be that hard to implement in mc, too. of course this doesn't help with conflicting changes, but that's obvious and part of the mental model. I think that auto save setup is something that cannot be implemented reliably in mc unless you make Ok work exactly like Save and save changes immediately. this is what both kde and gnome do, so i think it's safe to assume it is a reasonable approach. as far as remembering the last directory is concerned: that's sort of poor man's session management, not option management. it's basically the same as remembering the last position in the viewer and editor. i.e., there should be a separate option for enabling it. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
