Re: [PATCH] RPM vfs ignores conflicts
Hi Leonard,
On Tue, 2006-10-31 at 20:44 +0100, Leonard den Ottolander wrote:
Hi Jindrich,
On Tue, 2006-10-31 at 16:07 +0100, Jindrich Novy wrote:
the current RPM vfs allows to see RPM package requires/provides and
obsoletes but lacks an implementation of conflicts. The attached patch
adds INFO/CONFLICTS to the RPM vfs so that conflicts are no more hidden.
While you're at it, could you provide a similar patch for rpms please?
sure :) here we go with the patched trpm vfs as well. rpms fortunately
doesn't need any changes.
Cheers,
Jindrich
--- mc/vfs/extfs/rpm.rpmconf 2006-08-01 23:03:18.0 +0200
+++ mc/vfs/extfs/rpm 2006-10-31 12:54:41.0 +0100
@@ -122,12 +122,15 @@
echo $FILEPREF 0 $DATE INFO/OBSOLETES
$RPM -qp --qf [%{PROVIDES}\n] $f | grep (none) /dev/null ||
echo $FILEPREF 0 $DATE INFO/PROVIDES
+$RPM -qp --qf [%{CONFLICTS}\n] $f | grep (none) /dev/null ||
+ echo $FILEPREF 0 $DATE INFO/CONFLICTS
test `$RPM -qp --qf \%{CHANGELOGTEXT}\ \$f\` = (none) ||
echo $FILEPREF 0 $DATE INFO/CHANGELOG
else
echo $FILEPREF 0 $DATE INFO/REQUIRENAME
echo $FILEPREF 0 $DATE INFO/OBSOLETES
echo $FILEPREF 0 $DATE INFO/PROVIDES
+ echo $FILEPREF 0 $DATE INFO/CONFLICTS
echo $FILEPREF 0 $DATE INFO/CHANGELOG
fi
@@ -171,6 +174,7 @@
INFO/CHANGELOG) $RPM -qp --qf [* %{CHANGELOGTIME:date} %{CHANGELOGNAME}\n%{CHANGELOGTEXT}\n\n]\n $f $3; exit 0;;
INFO/SIZE) $RPM -qp --qf %{SIZE} bytes\n $f $3; exit 0;;
INFO/OBSOLETES) $RPM -qp --qf [%{OBSOLETENAME} %|OBSOLETEFLAGS?{%{OBSOLETEFLAGS:depflags} %{OBSOLETEVERSION}}:{}|\n] $f $3; exit 0;;
+ INFO/CONFLICTS) $RPM -qp --qf [%{CONFLICTNAME} %{CONFLICTFLAGS:depflags} %{CONFLICTVERSION}\n] $f $3; exit 0;;
CONTENTS.cpio) $RPM2CPIO $1 $3; exit 0;;
*)
;;
--- mc/vfs/extfs/trpm.rpmconf 2006-08-01 23:03:18.0 +0200
+++ mc/vfs/extfs/trpm 2006-11-01 09:45:42.0 +0100
@@ -112,12 +112,15 @@
echo $FILEPREF 0 $DATE INFO/OBSOLETES
$RPM -q --qf [%{PROVIDES}\n] -- $1 | grep (none) /dev/null ||
echo $FILEPREF 0 $DATE INFO/PROVIDES
+$RPM -q --qf [%{CONFLICTS}\n] -- $1 | grep (none) /dev/null ||
+ echo $FILEPREF 0 $DATE INFO/CONFLICTS
test `$RPM -q --qf \%{CHANGELOGTEXT}\ -- $1` = (none) ||
echo $FILEPREF 0 $DATE INFO/CHANGELOG
else
echo $FILEPREF 0 $DATE INFO/REQUIRENAME
echo $FILEPREF 0 $DATE INFO/OBSOLETES
echo $FILEPREF 0 $DATE INFO/PROVIDES
+ echo $FILEPREF 0 $DATE INFO/CONFLICTS
echo $FILEPREF 0 $DATE INFO/CHANGELOG
fi
@@ -148,6 +151,7 @@
INFO/REQUIRENAME) $RPM -q --qf [%{REQUIRENAME} %{REQUIREFLAGS:depflags} %{REQUIREVERSION}\n] -- $1 $3; exit 0;;
INFO/OBSOLETES) $RPM -q --qf [%{OBSOLETENAME} %|OBSOLETEFLAGS?{%{OBSOLETEFLAGS:depflags} %{OBSOLETEVERSION}}:{}|\n] -- $1 $3; exit 0;;
INFO/PROVIDES) $RPM -q --qf [%{PROVIDES}\n] -- $1 $3; exit 0;;
+ INFO/CONFLICTS) $RPM -q --qf [%{CONFLICTS}\n] -- $1 $3; exit 0;;
INFO/SCRIPTS/PREIN) $RPM -q --qf %{RPMTAG_PREIN}\n -- $1 $3; exit 0;;
INFO/SCRIPTS/POSTIN) $RPM -q --qf %{RPMTAG_POSTIN}\n -- $1 $3; exit 0;;
INFO/SCRIPTS/PREUN) $RPM -q --qf %{RPMTAG_PREUN}\n -- $1 $3; exit 0;;
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] RPM vfs ignores conflicts
Hi Jindrich, On Wed, 2006-11-01 at 10:23 +0100, Jindrich Novy wrote: sure :) here we go with the patched trpm vfs as well. rpms fortunately doesn't need any changes. Yes, of course, trpm. Committed. Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18042] cannot specify port number in shell link
Hello Andrew, On Mon, 2006-10-30 at 12:04 +, Andrew V. Samoilov wrote: Follow-up Comment #3, bug #18042 (project mc): Do I understand correctly that a port number *can* be combined with C _or_ r? No. Look at utilvfs.c:vfs_split_url(). No one syntax change. Only undocumented behaviour changed. It is possible to use /#sh:[EMAIL PROTECTED]:6789 right now. Maybe we should introduce a syntax change, because at least the combination of a port number and C are very welcome. What about a solution whereby the user can add any of these options, in any particular order, all separated by colons? Would that be a lot of work to implement? And fish uses port1 as 'C' option and port2 as 'r'. Possible solution is to use 0x11 and 0x12 instead of 1 and 2. That would probably get rid of the need for an extra parameter to separate the port number from other options. I am not sure we can allow such redesign because of lack of manpower. Do I understand correctly that you are not willing to implement such a change? Can we at least agree on a new syntax if somebody (I?) would be willing to implement it? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #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, 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). Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in existing scripts to bother with 3.2.x). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ 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, 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. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hello Pavel, On Wed, 2006-11-01 at 13:27 +0200, Pavel Tsekov wrote: Yes, I read that comment. However I'm not prepared to start breaking the functionality of shells that I never use. This is a rather strange statement. As a developer you should try to go beyond your personal preferences. As I have limited time I will not be implementing a solution where we replace echo -e with printf. It's not that I don't prefer such a solution, it's just that I will not be implementing it as it will take me too much time. As we are faced with an acute breaking when using bash = 3.2 I am prepared to create a patch that fixes the octal issue. Please let me know if you will be fixing the issue properly by replacing echo -e with printf. If not I will create a fix for the octals issue as the breakage of bash 3.2 needs to be fixed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
On Wed, 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 #18136] MC wont work with new bash-3.2 propeply with all directories.
On Wed, 2006-11-01 at 14:55 +0200, Pavel Tsekov wrote: I am beginning to wonther whether do we really want to escape the characters using echo or printf. For embedded backslashes etc. I suppose we do. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hello Thomas, On Wed, 2006-11-01 at 07:51 -0500, Thomas Dickey wrote: Before rushing off to change things to accommodate bash 3.2, it's worth checking if the fix will work with other shells. I'm not quite sure which fix you are referring to here. The temporary hack I send to this list should not break the other shells. All it does is add quoting of numbers for these shells. For the (temporary, echo -e) fix I had in mind even this change would be dropped. My idea was to add an ini option bash_oct_digits with possible values 0 (or unset) (automatically detect version via BASH_VERSION in the calling environment (actually querying the subshell seems a bit much) or fallback), 1 (compatibility mode, 4 digit octals with numbers quoted, for bash = 2.05b), 3 (legacy mode, only use 3 digit octals, no need to escape digits) and 4 (use 4 digit octals only, no need to escape digits, for bash = 3.2). Please let me know if there are volunteers to implement the proper solution (using printf) so I don't have to waste my time on a patch that is unnecessary. Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18042] cannot specify port number in shell link
Hello Pavel, On Wed, 2006-11-01 at 13:20 +0200, Pavel Tsekov wrote: IMO, it would be better if MC pops up an url specific dialog for each vfs if necessary so that the user could finer tune the connection. I think this would also help to add support for per connection settings i.e. use passive ftp for one connection and active for another. Instead of simple hacks we'd better go with well designed features. Agreed. But as Andrew also pointed out manpower is limited, so sadly we will sometimes have to use hacks if nobody is volunteering to invest time in the proper solution. They are not optimal, but in some cases better than not fixing breakage at all. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
On Wed, 2006-11-01 at 15:15 +0200, Pavel Tsekov wrote: The printf solution wouldn't be that hard to implement in fact. It may be even simpler. I can look at it. That would be nice. Thank you. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18042] cannot specify port number in shell link
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: [bug #18042] cannot specify port number in shell link
Hello Pavel, On Wed, 2006-11-01 at 15:26 +0200, Pavel Tsekov wrote: This is not a task which requires tremendous efforts. It is just a matter of defining what we want to do and how we want to do it. And in the meantime there is an easy workaround - just set the port in ~/.ssh/config. Yes, with the we sometimes need hacks I was not referring to this issue. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.
Hello Thomas, On Wed, 2006-11-01 at 08:38 -0500, Thomas Dickey wrote: One problem is that the user has to keep track (for the non-automatic workarounds) of the bash version. No. Default setting of 0 (or unset) of bash_octal_digits would fallback to option 1, which works for bash = 2.05b (in contrast to the current situation where by default only bash 3.2 will work). Only users of bash 2.05b will have to either export BASH_VERSION (iiuc BASH_VERSINFO is a set variable, not an environment var so unusable unless one directly queries the subshell) or set bash_octal_digits to 3. Pavel's the person to talk to (I maintain other programs including ncurses) - my point here was noting that bash 3.2 added other problems which are definitely _bugs_ in bash, and that it would not be good to cite 3.2 itself as a good example, but to focus on the feature. The issue of the octal length is independent of any bugs in bash 3.2 and will also exist for later versions. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: find in viewer
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. Regards, Nerijus On Tue, 23 May 2006 15:44:30 +0300 (EEST) Pavel Tsekov [EMAIL PROTECTED] wrote: On Thu, May 18, 2006 at 05:42:45PM +0300, Pavel Tsekov wrote: I guess in the long term the last seach string should be remembered onto persistent storage as for example the file positions. yes. How about the following patch ? This is not a final version - I am just posting it to see whether you like the idea. The patch uses the input field's ability to automatically retrieve the last entered text from the history. The last search expression would be loaded in the input field even after you've exited MC and then launch it again - this differs from the old behaviour where the search expression would be lost on MC exit. view-persistent-search.patch Description: Binary data ___ 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
