From kai at cmail.ru Mon Oct 1 14:00:54 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Mon, 01 Oct 2001 17:00:54 +0300 Subject: cd something.patch.gz#ugz#patchfs fixed Message-ID: <3BB87716.1F6D8D7A@cmail.ru> Hi! This patch fixes unpleasant feature of current mc: it exits with error message if you want cd to something like ???.patch.gz#ugz#patchfs. Regards, Andrew. ChangeLog: sfc.c (sfs_getid): Don't use vfs_die (), return (vfsid)(-1) instead. Index: sfs.c =================================================================== RCS file: /cvs/gnome/mc/vfs/sfs.c,v retrieving revision 1.31 diff -u -p -r1.31 sfs.c --- sfs.c 2001/08/11 04:57:17 1.31 +++ sfs.c 2001/10/01 13:23:01 @@ -220,10 +220,11 @@ static vfsid sfs_getid (vfs *me, char *p break; cur = cur->next; } - if (!cur) - vfs_die( "sfs_getid of noncached thingie?" ); *parent = NULL; + + if (!cur) + return (vfsid)(-1); { char *path2 = g_strdup (path); From proski at gnu.org Tue Oct 2 08:12:42 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 2 Oct 2001 04:12:42 -0400 (EDT) Subject: cd something.patch.gz#ugz#patchfs fixed In-Reply-To: <3BB87716.1F6D8D7A@cmail.ru> Message-ID: Hello, Andrew! > This patch fixes unpleasant feature of current mc: it exits with error > message if you want cd to something like ???.patch.gz#ugz#patchfs. The patch seems to be correct if we can talk about correctness of code full of static variables and pretending to be reentrant :-) I'm applying your patch, leaving it to Pavel Machek to review it and revert it if we both are missing something (unlikely). -- Regards, Pavel Roskin From hpstr at operamail.com Tue Oct 2 23:35:04 2001 From: hpstr at operamail.com (Hans Peter Stroebel) Date: Wed, 3 Oct 2001 01:35:04 +0200 Subject: Bug report : MC freezes reproducable when requesting SSH password for Fish VFS Message-ID: <01100300300300.12121@yankee> Hello List-Members, I experienced the following problem with MC, console edition, different versions (see below) on Linux : When using the Fish virtual file system by connecting to a server running SSH, entering the virtual directory cd /#sh:user at host , SSH requests the user`s password when RSA (or other method) authentication fails. This password request freezes MC after displaying the "Waiting for an initial line..." message, messing up the console output (sometimes the request appears on top of the screen, sometimes at the bottom). MC does not accept any more input and has to be forcely killed. Trying the FTP VFS instead results in a "regular" console graphics password window. Fish works fine if SSH can authenticate the user using RSA, but that could be sometimes (e.g. in my case) not the desired authentication method. I produced this failure with the following GNU/Linux systems / versions : - Debian potato, mc 4.52-11 (Debian package) - Debian potato, mc 4.55 (compiled from source). Kernel, Bash, SSH versions on request. Users from de.comp.os.unix.linux.misc reproduced the error with - Debian sid, MC version unknown - SuSe (Version unknown), MC 4.5.50 - RedHat 7.1, MC 4.5.51 (Kernel, Bash SSH version reported) - Debian woody and Mandrake reports pending so I suppose it is a MC bug and not consequence of misconfiguration. I did not find the bug neither in the list archives nor in the Debian bug tracking system (am I the only one desiring Fish/SSH/password auth ???), so I hope that here is the right place to report it. I tried to check the 4.55 source code for differences between SSH and FTP password request detection, but it seems to be quite beyond my capabilities, so I can`t include any bugfix suggestions; indeed, I can only _assume_ that the reason for the error is in the code piece that recognizes the password request. A fix would be highly welcome, as I consider the MC Fish VFS as a _very_ interesting alternative to scp, sftp or ftp tunneling. Greetings from Germany (and, BTW, thanks to the developers for this great swiss-army knife). Hans -- Hans Peter Stroebel Yes, I do. But not Yahoo. From proski at gnu.org Wed Oct 3 04:25:10 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Oct 2001 00:25:10 -0400 (EDT) Subject: Bug report : MC freezes reproducable when requesting SSH password for Fish VFS In-Reply-To: <01100300300300.12121@yankee> Message-ID: Hello, Hans! > I experienced the following problem with MC, console edition, different > versions (see below) on Linux : > > When using the Fish virtual file system by connecting to a server running > SSH, entering the virtual directory > > cd /#sh:user at host , > > SSH requests the user`s password when RSA (or other method) authentication > fails. Unfortunately, ssh insists on reading passwords from /dev/tty, which makes it quite hard for MC to feed the password to ssh. If you look into fish.c, you would find that MC is supposed to show you an error message "Sorry, we can not do password authenticated connections for now." I understand from you description that it doesn't work this way for you. If you have a hacked ssh that supports the "-I" option (read from stdin), you can define HAVE_HACKED_SSH and then MC is supposed to ask yuo the password and feed it to ssh through stdin. This doesn't seem to be documented anywhere outside the source. I believe, this functionality can be improved. In the meantime, fish can only be used over ssh connections that don't require a password. > This password request freezes MC after displaying the "Waiting for an initial > line..." message, messing up the console output (sometimes the request > appears on top of the screen, sometimes at the bottom). MC does not accept > any more input and has to be forcely killed. That's clearly a bug. > Trying the FTP VFS instead results in a "regular" console graphics password > window. MC uses its own FTP client implementation. It doesn't run a separate program and therefore has no problems interacting with it. > Fish works fine if SSH can authenticate the user using RSA, but that could be > sometimes (e.g. in my case) not the desired authentication method. It should also be possible to hack ssh to read stdin if "-I" is specified. I don't know if there are any patches available. > so I suppose it is a MC bug and not consequence of misconfiguration. Correct. I must add that apart from the bug (not showing the warning) there is a missing feature (inability to feed the password to ssh). > A fix would be highly welcome, as I consider the MC Fish VFS as a _very_ > interesting alternative to scp, sftp or ftp tunneling. I agree with you. Fixes to the existing code are welcome, much more than new half-implemented features. -- Regards, Pavel Roskin From mpol at gmx.net Wed Oct 3 12:57:38 2001 From: mpol at gmx.net (Marcel Pol) Date: Wed, 3 Oct 2001 14:57:38 +0200 Subject: ogg123 in mc.ext Message-ID: <20011003145738.1ff0c7cf.mpol@gmx.net> Hello, I have a feature request for mc. I usually use mc to play my audiofiles, and I'm missing ogg123 support in mc.ext. Could it be added to it? I changed the mp3 entry for mpg123 to ogg123, which works fine here: I removed the MPEG option, because I assume an ogg isn't an mpeg. I like to play my mp3's through mc, but I'm switching to ogg's, and I'd love it if mc had support for that be default. Btw, I'm not subscribed to this list so please cc a reply to my adress. Patch on 4.5.55: --- mc.ext-org Mon Oct 1 15:54:35 2001 +++ mc.ext Wed Oct 3 14:45:57 2001 @@ -260,6 +260,11 @@ Open=mpg123 %f View=%view{ascii} mpg123 -tn1 %f 2>&1|grep -E "^(Title|Album|Comment|MPEG|$)" +regex/\.(ogg|OGG|Ogg)$ + Open=ogg123 %f + View=%view{ascii} ogg123 -tn1 %f 2>&1|grep -E "^(Title|Album|Comment|$)"+ + ### Multimedia ### Greetings, -- Marcel Pol mpol at gmx.net From proski at gnu.org Wed Oct 3 18:51:41 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 3 Oct 2001 14:51:41 -0400 (EDT) Subject: ogg123 in mc.ext In-Reply-To: <20011003145738.1ff0c7cf.mpol@gmx.net> Message-ID: Hello, Marcel! > I have a feature request for mc. > I usually use mc to play my audiofiles, and I'm missing ogg123 support > in mc.ext. > Could it be added to it? Yes, of course. > I changed the mp3 entry for mpg123 to ogg123, which works fine here: > I removed the MPEG option, because I assume an ogg isn't an mpeg. I don't see that you removed anything. Maybe you mean "MPEG" from the regular expression? > I like to play my mp3's through mc, but I'm switching to ogg's, and > I'd love it if mc had support for that be default. Yes, it certainly deserves to be there. > +regex/\.(ogg|OGG|Ogg)$ > + Open=ogg123 %f > + View=%view{ascii} ogg123 -tn1 %f 2>&1|grep -E > "^(Title|Album|Comment|$)"+ What version of ogg123 are you using? Mine is "Ogg123 from vorbis-tools 1.0beta4" and it doesn't support the "-tn1" option. -- Regards, Pavel Roskin From mpol at gmx.net Wed Oct 3 22:10:59 2001 From: mpol at gmx.net (Marcel Pol) Date: Thu, 4 Oct 2001 00:10:59 +0200 Subject: ogg123 in mc.ext In-Reply-To: References: <20011003145738.1ff0c7cf.mpol@gmx.net> Message-ID: <20011004001059.3a506378.mpol@gmx.net> On Wed, 3 Oct 2001 14:51:41 -0400 (EDT) Pavel Roskin wrote: > > I have a feature request for mc. > > I usually use mc to play my audiofiles, and I'm missing ogg123 support > > in mc.ext. > > Could it be added to it? > > Yes, of course. Thanks :) > > I changed the mp3 entry for mpg123 to ogg123, which works fine here: > > I removed the MPEG option, because I assume an ogg isn't an mpeg. > > I don't see that you removed anything. Maybe you mean "MPEG" from the > regular expression? > > > I like to play my mp3's through mc, but I'm switching to ogg's, and > > I'd love it if mc had support for that be default. > > Yes, it certainly deserves to be there. > > > +regex/\.(ogg|OGG|Ogg)$ > > + Open=ogg123 %f > > + View=%view{ascii} ogg123 -tn1 %f 2>&1|grep -E > > "^(Title|Album|Comment|$)"+ > > What version of ogg123 are you using? Mine is "Ogg123 from vorbis-tools > 1.0beta4" and it doesn't support the "-tn1" option. Version 1.0rc2 here. But you're right. When playing it doesn't show any errors so i didn't take notice. I guess the -tn option can be removed then. -- Marcel Pol mpol at gmx.net From ka4inm at qsl.net Thu Oct 4 17:23:07 2001 From: ka4inm at qsl.net (Ron KA4INM Youvan) Date: Thu, 4 Oct 2001 13:23:07 -0400 Subject: ogg123 in mc.ext References: <20011003145738.1ff0c7cf.mpol@gmx.net> <20011004001059.3a506378.mpol@gmx.net> Message-ID: <006501c14cf9$3d63c180$93032e3f@wtog105> Hi all: snip > I changed the mp3 entry for mpg123 to ogg123, which works fine here: > I removed the MPEG option, because I assume an ogg isn't an mpeg. snip > I like to play my mp3's through mc, but I'm switching to ogg's, and > I'd love it if mc had support for that be default. snip I added ogg support right after the mp3 entry on `system wide' ectrntion rc file. You disabled the mp3 support because, you are sure you will never get a mp3 sent to you by a friend and you will never down load any mp3's again? I copied a 33kB wav file into a 27 kB ogg file, and I copied the same wav file into a 3 kB mp3, I don't see any reason to convert any of the mp3's in my collection to ogg format. The losses that occurred in converting the audio to mp3 remains lost after converting an mp3 to ogg, so there would be no gain other than a size increase. 73 (= Best Regards) de: (= this is) Ron ka4inm at qsl.net Please visit my HAM web site at: http://www.qsl.net/ka4inm From proski at gnu.org Fri Oct 5 06:09:57 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 5 Oct 2001 02:09:57 -0400 (EDT) Subject: ogg123 in mc.ext In-Reply-To: <006501c14cf9$3d63c180$93032e3f@wtog105> Message-ID: Hello, Ron! On Thu, 4 Oct 2001, Ron KA4INM Youvan wrote: > Hi all: > snip > > I changed the mp3 entry for mpg123 to ogg123, which works fine here: > > I removed the MPEG option, because I assume an ogg isn't an mpeg. > snip > > I like to play my mp3's through mc, but I'm switching to ogg's, and > > I'd love it if mc had support for that be default. > snip > > I added ogg support right after the mp3 entry on `system wide' > ectrntion rc file. > > You disabled the mp3 support because, you are sure you will > never get a mp3 sent to you by a friend and you will never > down load any mp3's again? Ron, I believe that you either didn't read the patch of didn't understand a single line in it. There is no way how adding or removing anything _after_ the rules for mp3 in mc.ext can affect support for mp3. Please don't write e-mail in this style about things that you don't understand. -- Regards, Pavel Roskin From proski at gnu.org Fri Oct 5 06:28:51 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 5 Oct 2001 02:28:51 -0400 (EDT) Subject: ogg123 in mc.ext In-Reply-To: <20011004001059.3a506378.mpol@gmx.net> Message-ID: Hi, Marcel! > > > +regex/\.(ogg|OGG|Ogg)$ > > > + Open=ogg123 %f > > > + View=%view{ascii} ogg123 -tn1 %f 2>&1|grep -E > > > "^(Title|Album|Comment|$)"+ > > > > What version of ogg123 are you using? Mine is "Ogg123 from > vorbis-tools > > 1.0beta4" and it doesn't support the "-tn1" option. > > Version 1.0rc2 here. > But you're right. > When playing it doesn't show any errors so i didn't take notice. > I guess the -tn option can be removed then. Of course playing is not affected. You put this option to the "View" rule. I think that the syntax of mc.ext is explained clearly in the beginning of the file, but you somehow missed this explanation. I'm open to suggestions how to make this description more visible or more understandable. It seems that both mpg123 and ogg123 lack a straightforward way to request metadata without playing the sound. "-tn1" for mpg123 means that only one frame should be decoded and it should not be played. I changed it to "-vtn1" so that the output is more verbose. I found similar options for ogg123 - it's a hack, but hopefully an option for requesting metadata will appear before this hack stops working. Here it is: View=%view{ascii} ogg123 -v -d null -k -1 %f 2>&1 | sed -n '/^Bitstream/,/^$/p' Works fine for me. "-v" is verbose, "-d null" means "don't play", "-k -1" means "play -1 seconds", which eliminates any delays. "sed" cuts the insteresting strings starting with "Bitstream" and ending with an empty line. I also added support for *.mid (without viewer) and changed the "Open" rules to play *.mp3 and *.ogg in xmms if $DISPLAY is set. Here's the complete patch. -------------------------------------------- --- ChangeLog +++ ChangeLog @@ -1 +1,7 @@ +2001-10-05 Pavel Roskin + + * lib/mc.ext.in: Use xmms to play *.mp3 under X. When viewing + *.mp3, use "verbose" option to mpg123. Add support for *.ogg + and *.mid files. + 2001-09-30 Pavel Roskin --- lib/mc.ext.in +++ lib/mc.ext.in @@ -257,9 +257,15 @@ Open=vplay -s 22 %f regex/\.(mp3|MP3|Mp3)$ - Open=mpg123 %f - View=%view{ascii} mpg123 -tn1 %f 2>&1|grep -E "^(Title|Album|Comment|MPEG|$)" + Open=if [ "$DISPLAY" = "" ]; then mpg123 %f; else (xmms %f &); fi + View=%view{ascii} mpg123 -vtn1 %f 2>&1 | sed -n '/^Title/,/^Comment/p;/^MPEG/,/^Audio/p' +regex/\.(ogg|OGG|Ogg)$ + Open=if [ "$DISPLAY" = "" ]; then ogg123 %f; else (xmms %f &); fi + View=%view{ascii} ogg123 -v -d null -k -1 %f 2>&1 | sed -n '/^Bitstream/,/^$/p' + +regex/\.(midi?|MIDI?|Midi?)$ + Open=timidity %f ### Multimedia ### -------------------------------------------- -- Regards, Pavel Roskin From root at sav.it.efp.com.ua Fri Oct 5 07:43:53 2001 From: root at sav.it.efp.com.ua (root at sav.it.efp.com.ua) Date: Fri, 5 Oct 2001 10:43:53 +0300 (EEST) Subject: Eliminate egrep -q in mc.menu Message-ID: <200110050743.f957hrG00544@sav.it.efp.com.ua> Hi! This patch eliminate unportable egrep -q usage in mc.menu file. It seems case xxx in *.tgz) is more portable. If it is really so I can rewrite mc.menu in such order at all. Best regards, Andrew. ChangeLog: lib/mc.menu: Eliminate egrep -q, use case instead. Index: mc.menu =================================================================== RCS file: /cvs/gnome/mc/lib/mc.menu,v retrieving revision 1.5 diff -u -p -r1.5 mc.menu --- mc.menu 2000/05/09 01:18:29 1.5 +++ mc.menu 2001/10/05 07:22:16 @@ -229,26 +229,17 @@ B Bzip2 or bunzip2 tagged files + f \.tar.gz$ | f \.tgz$ | f \.tpz$ | f \.tar.Z$ | f \.tar.z$ | f \.tar.bz2$ & t r & ! t t z Extract compressed tar file to subdirectory - unset D - echo %f|egrep -q "\.tar.gz$" && EXT=tar_gz - echo %f|egrep -q "\.tgz$" && EXT=tgz - echo %f|egrep -q "\.tpz$" && EXT=tpz - echo %f|egrep -q "\.tar.Z$" && EXT=tar_Z - echo %f|egrep -q "\.tar.z$" && EXT=tar_z - echo %f|egrep -q "\.tar.bz2$" && EXT=tar_bz2 - case $EXT in - tar_gz) D="`basename %f .tar.gz`";; - tgz) D="`basename %f .tgz`";; - tpz) D="`basename %f .tpz`";; - tar_Z) D="`basename %f .tar.Z`";; - tar_z) D="`basename %f .tar.z`";; - tar_bz2) D="`basename %f .tar.bz2`";; - esac - if [ "$EXT" = "tar_bz2" ]; then - mkdir $D; cd $D && (bunzip2 -c ../%f | tar xvf -) - else - mkdir $D; cd $D && (gzip -dc ../%f | tar xvf -) - fi + unset D + set gzip -cd + case %f in + *.tar.gz) D="`basename %f .tar.gz`";; + *.tgz) D="`basename %f .tgz`";; + *.tpz) D="`basename %f .tpz`";; + *.tar.Z) D="`basename %f .tar.Z`";; + *.tar.z) D="`basename %f .tar.z`";; + *.tar.bz2) D="`basename %f .tar.bz2`"; set bunzip2 -c ;; + esac + mkdir $D; cd $D && ($1 $2 ../%f | tar xvf -) + f \.tar.F$ & t r & ! t t z Extract compressed tar file to subdirectory From proski at gnu.org Fri Oct 5 08:38:06 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 5 Oct 2001 04:38:06 -0400 (EDT) Subject: Eliminate egrep -q in mc.menu In-Reply-To: <200110050743.f957hrG00544@sav.it.efp.com.ua> Message-ID: Hello! > This patch eliminate unportable egrep -q usage in mc.menu file. > It seems case xxx in *.tgz) is more portable. If it is really > so I can rewrite mc.menu in such order at all. That's correct. "egrep -q" doesn't work on Solaris 8. "case" is used in Autoconf, which means that it's _very_ portable. -- Regards, Pavel Roskin From "Andrew V. Samoilov" at gnome.org Fri Oct 5 10:24:18 2001 From: "Andrew V. Samoilov" at gnome.org ("Andrew V. Samoilov" at gnome.org) Date: Fri, 5 Oct 2001 13:24:18 +0300 (EEST) Subject: Replace egrep -q with case in mc.menu Message-ID: <200110051024.f95AOI802259@sav.it.efp.com.ua> Hello! This patch replaces all occurences of 'egrep -q' with case statements. As side effect compress file(s) can be really converted to bz2 format. Also tagged archives converting fixed. It seems this features are useless. Fill free to fix my English in ChangeLog. Regards, Andrew. ChangeLog: * lib/mc.menu: Use case instead of egrep -q. Fix compress<->bzip2 converting. Fix tagged archives converting. Index: mc.menu =================================================================== RCS file: /cvs/gnome/mc/lib/mc.menu,v retrieving revision 1.5 diff -u -p -u -r1.5 mc.menu --- mc.menu 2000/05/09 01:18:29 1.5 +++ mc.menu 2001/10/05 09:50:58 @@ -109,7 +109,7 @@ n Inspect gzip'ed newsbatch file = t r & + ! t t h Strip headers from current newsarticle - CHECK=`sed 1q < %f|awk '{print $1}'` 2>/dev/null + CHECK=`awk '{print $1 ; exit}' %f` 2>/dev/null case $CHECK in Newsgroups:|Path:) cp %f /tmp/%f.$$ && sed '/^'"$CHECK"' /,/^$/d' /tmp/%f.$$ > %f @@ -125,7 +125,7 @@ h Strip headers from current newsa H Strip headers from the marked newsarticles set %u while [ -n "$1" ]; do - CHECK=`sed 1q < $1|awk '{print $1}'` 2>/dev/null + CHECK=`awk '{print $1 ; exit}' $1` 2>/dev/null WFILE=/tmp/${1}.$$ case $CHECK in Newsgroups:|Path:) @@ -173,7 +173,7 @@ U Uudecode marked news articles (n set %u ( while [ -n "$1" ]; do # strip headers - FIRST=`sed 1q < $1|awk '{print $1}'` + FIRST=`awk '{print $1 ; exit}' $1` cat $1 | sed '/^'"$FIRST"' /,/^$/d'; shift done ) |sed '/^$/d' |sed -n '/^begin 6/,/^end$/p' | uudecode @@ -189,7 +189,9 @@ U Uudecode marked news articles (n =+ f \.tar\.gz$ | f \.tar\.z$ | f \.tgz$ | f \.tpz$ | f \.tar\.Z$| f \.tar\.bz2$ & t r x Extract the contents of a compressed tar file unset EXT - echo %f|egrep -q "\.tar.bz2$" && EXT=tar_bz2 + case %f in + *.tar.bz2) EXT=tar_bz2;; + esac if [ "$EXT" = "tar_bz2" ]; then bunzip2 -c %f | tar xvf - else @@ -200,7 +202,10 @@ x Extract the contents of a compre + ! t t y Gzip or gunzip current file unset DECOMP - echo %f|egrep -q "\.gz$|\.z$|\.Z$" && DECOMP=-d + case %f in + *.gz) DECOMP=-d;; + *.[zZ]) DECOMP=-d;; + esac gzip $DECOMP -v %f + t t @@ -208,14 +213,19 @@ Y Gzip or gunzip tagged files for i in %t do unset DECOMP - echo $i|egrep -q "\.gz$|\.z$|\.Z$" && DECOMP=-d + case $i in + *.gz) DECOMP=-d;; + *.[zZ]) DECOMP=-d;; + esac gzip $DECOMP -v $i done + ! t t b Bzip2 or bunzip2 current file unset DECOMP - echo %f|egrep -q "\.bz2$" && DECOMP=-d + case %f in + *.bz2) DECOMP=-d;; + esac bzip2 $DECOMP -v %f + t t @@ -223,86 +233,60 @@ B Bzip2 or bunzip2 tagged files for i in %t do unset DECOMP - echo $i|egrep -q "\.bz2$" && DECOMP=-d + case $i in + *.bz2) DECOMP=-d;; + esac bzip2 $DECOMP -v $i done -+ f \.tar.gz$ | f \.tgz$ | f \.tpz$ | f \.tar.Z$ | f \.tar.z$ | f \.tar.bz2$ & t r & ! t t ++ f \.tar.gz$ | f \.tgz$ | f \.tpz$ | f \.tar.Z$ | f \.tar.z$ | f \.tar.bz2$ | f \.tar.F$ & t r & ! t t z Extract compressed tar file to subdirectory - unset D - echo %f|egrep -q "\.tar.gz$" && EXT=tar_gz - echo %f|egrep -q "\.tgz$" && EXT=tgz - echo %f|egrep -q "\.tpz$" && EXT=tpz - echo %f|egrep -q "\.tar.Z$" && EXT=tar_Z - echo %f|egrep -q "\.tar.z$" && EXT=tar_z - echo %f|egrep -q "\.tar.bz2$" && EXT=tar_bz2 - case $EXT in - tar_gz) D="`basename %f .tar.gz`";; - tgz) D="`basename %f .tgz`";; - tpz) D="`basename %f .tpz`";; - tar_Z) D="`basename %f .tar.Z`";; - tar_z) D="`basename %f .tar.z`";; - tar_bz2) D="`basename %f .tar.bz2`";; - esac - if [ "$EXT" = "tar_bz2" ]; then - mkdir $D; cd $D && (bunzip2 -c ../%f | tar xvf -) - else - mkdir $D; cd $D && (gzip -dc ../%f | tar xvf -) - fi - -+ f \.tar.F$ & t r & ! t t -z Extract compressed tar file to subdirectory - unset D - echo %f|egrep -q "\.tar.F$" && EXT=tar_F - case $EXT in - tar_F) D="`basename %f .tar.F`";; + unset D + set gzip -cd + case %f in + *.tar.gz) D="`basename %f .tar.gz`";; + *.tgz) D="`basename %f .tgz`";; + *.tpz) D="`basename %f .tpz`";; + *.tar.Z) D="`basename %f .tar.Z`";; + *.tar.z) D="`basename %f .tar.z`";; + *.tar.bz2) D="`basename %f .tar.bz2`"; set bunzip2 -c ;; + *.tar.F) D="`basename %f .tar.F`"; set freeze -dc; esac - mkdir $D; cd $D && (freeze -dc ../%f | tar xvf -) + mkdir $D; cd $D && ($1 $2 ../%f | tar xvf -) + t t Z Extract compressed tar files to subdirectories - set %u - while [ -n "$1" ] + for i in %u do + set gzip -dc unset D - echo $1|egrep -q "\.tar.gz$" && EXT=tar_gz - echo $1|egrep -q "\.tgz$" && EXT=tgz - echo $1|egrep -q "\.tpz$" && EXT=tpz - echo $1|egrep -q "\.tar.Z$" && EXT=tar_Z - echo $1|egrep -q "\.tar.z$" && EXT=tar_z - echo $1|egrep -q "\.tar.F$" && EXT=tar_F - echo $1|egrep -q "\.tar.bz2$" && EXT=tar_bz2 - case $EXT in - tar_gz) D="`basename $1 .tar.gz`";; - tgz) D="`basename $1 .tgz`";; - tpz) D="`basename $1 .tpz`";; - tar_Z) D="`basename $1 .tar.Z`";; - tar_z) D="`basename $1 .tar.z`";; - tar_F) D="`basename $1 .tar.F`";; - tar_bz2) D="`basename $1 .tar.bz2`";; + case $i in + *.tar.gz) D="`basename $1 .tar.gz`";; + *.tgz) D="`basename $1 .tgz`";; + *.tpz) D="`basename $1 .tpz`";; + *.tar.Z) D="`basename $1 .tar.Z`";; + *.tar.z) D="`basename $1 .tar.z`";; + *.tar.F) D="`basename $1 .tar.F`"; set freeze -dc;; + *.tar.bz2) D="`basename $1 .tar.bz2`"; set bunzip2 -c;; esac - case $EXT in - tar_gz|tgz|tpz|tar_Z|tar_z) mkdir $D; (cd $D && gzip -dc ../$1 | tar xvf -)||echo tag $1 >>$MC_CONTROL_FILE;; - tar_F) mkdir $D; (cd $D && freeze -dc ../$1 | tar xvf -)||echo tag $1 >>$MC_CONTROL_FILE;; - tar_bz2) mkdir $D; (cd $D && bunzip2 -c ../$1 | tar xvf -)||echo tag $1 >>$MC_CONTROL_FILE - esac - shift + mkdir $D; (cd $D && $1 $2 ../$i | tar xvf -)||echo tag $i >>$MC_CONTROL_FILE done + f \.gz$ | f \.tgz$ | f \.tpz$ | f \.Z$ | f \.z$ | f \.bz2$ & t r & ! t t c Convert gz<->bz2, tar.gz<->tar.bz2 & tgz->tar.bz2 unset D - echo %f|egrep -q "\.tgz$" && EXT=tgz - echo %f|egrep -q "\.tpz$" && EXT=tpz - echo %f|egrep -q "\.Z$" && EXT=Z - echo %f|egrep -q "\.z$" && EXT=z - echo %f|egrep -q "\.gz$" && EXT=gz - echo %f|egrep -q "\.bz2$" && EXT=bz2 + case %f in + *.tgz) EXT=tgz;; + *.tpz) EXT=tpz;; + *.Z) EXT=Z;; + *.z) EXT=z;; + *.gz) EXT=gz;; + *.bz2) EXT=bz2;; + esac case $EXT in - tgz) D="`basename %f .tgz`.tar";; - tpz) D="`basename %f .tpz`.tar";; - gz) D="`basename %f .gz`";; - bz2) D="`basename %f .bz2`";; + tgz|tpz) D="`basename %f .$EXT`.tar";; + gz|Z|z) D="`basename %f .$EXT`";; + bz2) D="`basename %f .bz2`";; esac if [ "$EXT" = "bz2" ]; then bunzip2 -v %f ; gzip -f9 -v $D @@ -316,17 +300,19 @@ C Convert gz<->bz2, tar.gz<->tar.b while [ -n "$1" ] do unset D - echo %f|egrep -q "\.tgz$" && EXT=tgz - echo %f|egrep -q "\.tpz$" && EXT=tpz - echo %f|egrep -q "\.Z$" && EXT=Z - echo %f|egrep -q "\.z$" && EXT=z - echo %f|egrep -q "\.gz$" && EXT=gz - echo %f|egrep -q "\.bz2$" && EXT=bz2 + case $1 in + *.tgz) EXT=tgz;; + *.tpz) EXT=tpz;; + *.Z) EXT=Z;; + *.z) EXT=z;; + *.gz) EXT=gz;; + *.bz2) EXT=bz2;; + esac case $EXT in tgz) D="`basename $1 .tgz`.tar";; tpz) D="`basename $1 .tpz`.tar";; - gz) D="`basename $1 .gz`";; - bz2) D="`basename $1 .bz2`";; + gz|Z|z) D="`basename $1 .$EXT`";; + bz2) D="`basename $1 .bz2`";; esac if [ "$EXT" = "bz2" ]; then (bunzip2 -v $1 ; gzip -f9 -v $D)||echo tag $1 >>$MC_CONTROL_FILE From mpol at gmx.net Fri Oct 5 17:18:59 2001 From: mpol at gmx.net (Marcel Pol) Date: Fri, 5 Oct 2001 19:18:59 +0200 Subject: ogg123 in mc.ext In-Reply-To: References: <20011004001059.3a506378.mpol@gmx.net> Message-ID: <20011005191859.4746bc13.mpol@gmx.net> On Fri, 5 Oct 2001 02:28:51 -0400 (EDT) Pavel Roskin wrote: > > > > +regex/\.(ogg|OGG|Ogg)$ > > > > + Open=ogg123 %f > > > > + View=%view{ascii} ogg123 -tn1 %f 2>&1|grep -E > > > > "^(Title|Album|Comment|$)"+ > > > > > > What version of ogg123 are you using? Mine is "Ogg123 from > > vorbis-tools > > > 1.0beta4" and it doesn't support the "-tn1" option. > Of course playing is not affected. You put this option to the "View" > rule. I think that the syntax of mc.ext is explained clearly in the > beginning of the file, but you somehow missed this explanation. I'm open > to suggestions how to make this description more visible or more > understandable. Well, I just didn't take the time to read it. Never knew you could use F3 to "view" an mp3 or ogg. Mc just has too many features :) > It seems that both mpg123 and ogg123 lack a straightforward way to request > metadata without playing the sound. "-tn1" for mpg123 means that only one > frame should be decoded and it should not be played. I changed it to > "-vtn1" so that the output is more verbose. > > I found similar options for ogg123 - it's a hack, but hopefully an option > for requesting metadata will appear before this hack stops working. Here > it is: > > View=%view{ascii} ogg123 -v -d null -k -1 %f 2>&1 | sed -n '/^Bitstream/,/^$/p' > > Works fine for me. "-v" is verbose, "-d null" means "don't play", "-k -1" > means "play -1 seconds", which eliminates any delays. "sed" cuts the > insteresting strings starting with "Bitstream" and ending with an empty > line. Here it gives me this output on an ogg file: Bitstream is 2 channel, 44100Hz Time: 05:17.85 [00:-0.01] of 05:17.84, Bitrate: 220.2 Done. ao_null: 3656 bytes sent to null device. I can't say that's too interesting. I'd rather see the title, album, artist and bitrate. Maybe ogginfo is better for this. It doesn't accept any options though, so maybe grepping the interesting lines might be appropriate? What I'd prefer would look like this: ogginfo %f 2>&1|grep -E "^(title|artist|album|bitrate_nominal|playtime|$)" > I also added support for *.mid (without viewer) and changed the "Open" > rules to play *.mp3 and *.ogg in xmms if $DISPLAY is set. Well, I don't really know what to say to that. The reason why i use mc is because it's lightweight, flexible and featurefull. I can't agree on the lightweight part of xmms. For midi, I don't use midi, but if it wasn't in mc.ext yet, it is a good idea to put it in as well. > Here's the complete patch. > > -------------------------------------------- > --- ChangeLog > +++ ChangeLog > @@ -1 +1,7 @@ > +2001-10-05 Pavel Roskin > + > + * lib/mc.ext.in: Use xmms to play *.mp3 under X. When viewing > + *.mp3, use "verbose" option to mpg123. Add support for *.ogg > + and *.mid files. > + > 2001-09-30 Pavel Roskin > --- lib/mc.ext.in > +++ lib/mc.ext.in > @@ -257,9 +257,15 @@ > Open=vplay -s 22 %f > > regex/\.(mp3|MP3|Mp3)$ > - Open=mpg123 %f > - View=%view{ascii} mpg123 -tn1 %f 2>&1|grep -E "^(Title|Album|Comment|MPEG|$)" > + Open=if [ "$DISPLAY" = "" ]; then mpg123 %f; else (xmms %f &); fi > + View=%view{ascii} mpg123 -vtn1 %f 2>&1 | sed -n '/^Title/,/^Comment/p;/^MPEG/,/^Audio/p' > > +regex/\.(ogg|OGG|Ogg)$ > + Open=if [ "$DISPLAY" = "" ]; then ogg123 %f; else (xmms %f &); fi > + View=%view{ascii} ogg123 -v -d null -k -1 %f 2>&1 | sed -n '/^Bitstream/,/^$/p' > + > +regex/\.(midi?|MIDI?|Midi?)$ > + Open=timidity %f > > ### Multimedia ### --- Marcel Pol mpol at gmx.net From proski at gnu.org Fri Oct 5 22:35:22 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 5 Oct 2001 18:35:22 -0400 (EDT) Subject: ogg123 in mc.ext In-Reply-To: <20011005191859.4746bc13.mpol@gmx.net> Message-ID: Hello, Marcel! > Here it gives me this output on an ogg file: > Bitstream is 2 channel, 44100Hz > Time: 05:17.85 [00:-0.01] of 05:17.84, Bitrate: 220.2 > Done. > ao_null: 3656 bytes sent to null device. Not nice. > I can't say that's too interesting. > I'd rather see the title, album, artist and bitrate. > Maybe ogginfo is better for this. It doesn't accept any options > though, so maybe grepping the interesting lines might be appropriate? Thank you. I didn't know about ogginfo. It's much better to use specialized software that to trick the player into displaying the info. > > I also added support for *.mid (without viewer) and changed the > "Open" > > rules to play *.mp3 and *.ogg in xmms if $DISPLAY is set. > > Well, I don't really know what to say to that. > The reason why i use mc is because it's lightweight, flexible and > featurefull. > I can't agree on the lightweight part of xmms. I'm just trying to follow the existing tradition, when mc tries to use X programs under X so that they run in a separate window and MC is ready to be used immediately. -- Regards, Pavel Roskin From proski at gnu.org Sat Oct 6 08:58:09 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 6 Oct 2001 04:58:09 -0400 (EDT) Subject: Replace egrep -q with case in mc.menu In-Reply-To: <200110051024.f95AOI802259@sav.it.efp.com.ua> Message-ID: Hello! > ChangeLog: > * lib/mc.menu: Use case instead of egrep -q. > Fix compress<->bzip2 converting. > Fix tagged archives converting. I've applied this patch. Since you are using strange return addresses root at sav.it.efp.com.ua and "Andrew V. Samoilov"@gnome.org, I used your old address in the ChangeLog. Thank you for your help! -- Regards, Pavel Roskin From hpstr at operamail.com Sat Oct 6 22:41:12 2001 From: hpstr at operamail.com (Hans Peter Stroebel) Date: Sun, 7 Oct 2001 00:41:12 +0200 Subject: Bug report : MC freezes reproducable when requesting SSH password for Fish VFS In-Reply-To: References: Message-ID: <01100700403301.04679@yankee> Am Mittwoch, 3. Oktober 2001 06:25 schrieb Pavel Roskin: Hi Pavel ! > Unfortunately, ssh insists on reading passwords from /dev/tty, which makes > it quite hard for MC to feed the password to ssh. If you look into > fish.c, you would find that MC is supposed to show you an error message > > "Sorry, we can not do password authenticated connections for now." > > I understand from you description that it doesn't work this way for you. Right, mc hangs before displaying this message. > If you have a hacked ssh that supports the "-I" option (read from stdin), > you can define HAVE_HACKED_SSH and then MC is supposed to ask yuo the > password and feed it to ssh through stdin. > > This doesn't seem to be documented anywhere outside the source. > I believe, this functionality can be improved. In the meantime, fish Due to _very_ low programming skills I`m not able to even try to provide a solution :-( > can only be used over ssh connections that don't require a password. Maybe at least a note in the manpage as a Q&D solution ? ;-) > > This password request freezes MC after displaying the "Waiting for an > > initial line..." message, messing up the console output (sometimes the > > request appears on top of the screen, sometimes at the bottom). MC does > > not accept any more input and has to be forcely killed. > > That's clearly a bug. I tried it in the meantime with an RSA key containing a passphrase, same problem. It works only if the SSH authentication doesn`t require _any_ user interaction (RSA key with empty passphrase). > It should also be possible to hack ssh to read stdin if "-I" is specified. > I don't know if there are any patches available. I did not look at the ssh source yet, but I don`t know even if I would be able to do it if it isn`t implemented as an option in the source. Do you have any further info ? > > A fix would be highly welcome, as I consider the MC Fish VFS as a _very_ > > interesting alternative to scp, sftp or ftp tunneling. > > I agree with you. Fixes to the existing code are welcome, much more than > new half-implemented features. I tried to use a wrapper perl script around the ssh client, but it fails because of the same problem : no input from stdin. Trying it with an RSA key without passphrase, I noticed that fish vfs is _really_ cool ! Compliments.... Anyway, thanks for mc to all devel folks and for your quick response. cu Hans -- Hans Peter Stroebel Yes, I do. But not Yahoo. From pavel at ucw.cz Tue Oct 2 22:32:05 2001 From: pavel at ucw.cz (Pavel Machek) Date: Tue, 2 Oct 2001 22:32:05 +0000 Subject: vfs.c "Could not parse" In-Reply-To: <3BB46668.6BD195F9@cmail.ru>; from kai@cmail.ru on Fri, Sep 28, 2001 at 03:00:40PM +0300 References: <3BB2E50C.EF7AB81E@vz.cit.alcatel.fr> <3BB46668.6BD195F9@cmail.ru> Message-ID: <20011002223204.A87@toy.ucw.cz> Hi! > > This FTP server outputs the file dates with Frech format: > > > > 150 ASCII data connection for /bin/ls (139.54.66.187,1071) (0 bytes). > > total 15740 > > drwxr-xr-x 6 root other 512 sep 26 16:52 . > > drwxr-xr-x 3 root other 512 sep 25 14:43 .. > > drwxr-xr-x 13 root other 512 sep 26 15:23 apache > > drwxrwsr-x 28 root bin 1024 f.v 8 2001 ghost > > drwxr-xr-x 5 999 999 512 nov 27 2000 perl560 > > drwxr-xr-x 9 999 999 512 nov 3 2000 tomcat > > -rw-r--r-- 1 root other 8042496 sep 26 16:51 TOMCAT.03.01.sol.tar > > 226 ASCII Transfer complete. > > > > The table in > > static int > > is_month (char *str, struct tm *tim) > > { > > static char *month = "JanFebMarAprMayJunJulAugSepOctNovDec"; > > > > is obviously an English table, and is good for most servers. > > what can we do ? > > Some time ago we discussed this. Then extended ftpfs URL with > locale specifiacation was proposed. But it does not cure if you > have not required locale installed on your system. what about checking its three letters and if so, return ok but set date to 1970-01-01 to indicate date is wrong? -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From pavel at ucw.cz Tue Oct 2 22:36:54 2001 From: pavel at ucw.cz (Pavel Machek) Date: Tue, 2 Oct 2001 22:36:54 +0000 Subject: vfs/ftpfs New feature on Solaris 2.7 In-Reply-To: <200109271235.f8RCZ2C06124@sav.it.efp.com.ua>; from "Andrew V. Samoilov"@gnome.org on Thu, Sep 27, 2001 at 03:35:02PM +0300 References: <200109271235.f8RCZ2C06124@sav.it.efp.com.ua> Message-ID: <20011002223653.B87@toy.ucw.cz> Hi! > Index: vfs.c > =================================================================== > RCS file: /home/sav/.cvsroot/mc/vfs/vfs.c,v > retrieving revision 1.60 > diff -u -p -r1.60 vfs.c > --- vfs.c 25 May 2000 18:00:34 -0000 1.60 > +++ vfs.c 27 Sep 2001 12:18:48 -0000 > @@ -1439,9 +1442,10 @@ vfs_parse_filetype (char c) > return S_IFSOCK; > #endif > case 'p': return S_IFIFO; > + case 'D': /* Solaris door */ > case 'm': case 'n': /* Don't know what these are :-) */ > case '-': case '?': return S_IFREG; > default: return -1; > } > } Looks good! Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From pavel at ucw.cz Tue Oct 2 22:32:05 2001 From: pavel at ucw.cz (Pavel Machek) Date: Tue, 2 Oct 2001 22:32:05 +0000 Subject: vfs.c "Could not parse" In-Reply-To: <3BB46668.6BD195F9@cmail.ru>; from kai@cmail.ru on Fri, Sep 28, 2001 at 03:00:40PM +0300 References: <3BB2E50C.EF7AB81E@vz.cit.alcatel.fr> <3BB46668.6BD195F9@cmail.ru> Message-ID: <20011002223204.A87@toy.ucw.cz> Hi! > > This FTP server outputs the file dates with Frech format: > > > > 150 ASCII data connection for /bin/ls (139.54.66.187,1071) (0 bytes). > > total 15740 > > drwxr-xr-x 6 root other 512 sep 26 16:52 . > > drwxr-xr-x 3 root other 512 sep 25 14:43 .. > > drwxr-xr-x 13 root other 512 sep 26 15:23 apache > > drwxrwsr-x 28 root bin 1024 f.v 8 2001 ghost > > drwxr-xr-x 5 999 999 512 nov 27 2000 perl560 > > drwxr-xr-x 9 999 999 512 nov 3 2000 tomcat > > -rw-r--r-- 1 root other 8042496 sep 26 16:51 TOMCAT.03.01.sol.tar > > 226 ASCII Transfer complete. > > > > The table in > > static int > > is_month (char *str, struct tm *tim) > > { > > static char *month = "JanFebMarAprMayJunJulAugSepOctNovDec"; > > > > is obviously an English table, and is good for most servers. > > what can we do ? > > Some time ago we discussed this. Then extended ftpfs URL with > locale specifiacation was proposed. But it does not cure if you > have not required locale installed on your system. what about checking its three letters and if so, return ok but set date to 1970-01-01 to indicate date is wrong? -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From pavel at ucw.cz Tue Oct 2 22:36:54 2001 From: pavel at ucw.cz (Pavel Machek) Date: Tue, 2 Oct 2001 22:36:54 +0000 Subject: vfs/ftpfs New feature on Solaris 2.7 In-Reply-To: <200109271235.f8RCZ2C06124@sav.it.efp.com.ua>; from "Andrew V. Samoilov"@gnome.org on Thu, Sep 27, 2001 at 03:35:02PM +0300 References: <200109271235.f8RCZ2C06124@sav.it.efp.com.ua> Message-ID: <20011002223653.B87@toy.ucw.cz> Hi! > Index: vfs.c > =================================================================== > RCS file: /home/sav/.cvsroot/mc/vfs/vfs.c,v > retrieving revision 1.60 > diff -u -p -r1.60 vfs.c > --- vfs.c 25 May 2000 18:00:34 -0000 1.60 > +++ vfs.c 27 Sep 2001 12:18:48 -0000 > @@ -1439,9 +1442,10 @@ vfs_parse_filetype (char c) > return S_IFSOCK; > #endif > case 'p': return S_IFIFO; > + case 'D': /* Solaris door */ > case 'm': case 'n': /* Don't know what these are :-) */ > case '-': case '?': return S_IFREG; > default: return -1; > } > } Looks good! Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From proski at gnu.org Sun Oct 7 09:06:18 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 7 Oct 2001 05:06:18 -0400 (EDT) Subject: vfs.c "Could not parse" In-Reply-To: <20011002223204.A87@toy.ucw.cz> Message-ID: Hi, Pavel! > > Some time ago we discussed this. Then extended ftpfs URL with > > locale specifiacation was proposed. But it does not cure if you > > have not required locale installed on your system. > > what about checking its three letters and if so, return ok but set date > to 1970-01-01 to indicate date is wrong? Sound good to me. "Letters" should mean any ASCII letter or any character between 160 and 255. -- Regards, Pavel Roskin From pavel at ucw.cz Sun Oct 7 20:22:30 2001 From: pavel at ucw.cz (Pavel Machek) Date: Sun, 7 Oct 2001 22:22:30 +0200 Subject: vfs.c "Could not parse" In-Reply-To: <20011007210447.A858@bat.ru>; from Timur I. Bakeyev on Sun, Oct 07, 2001 at 09:04:47PM +0200 References: <20011002223204.A87@toy.ucw.cz> <20011007210447.A858@bat.ru> Message-ID: <20011007222230.B6207@bug.ucw.cz> Hi! > > > what about checking its three letters and if so, return ok but set date > > > to 1970-01-01 to indicate date is wrong? > > > > Sound good to me. "Letters" should mean any ASCII letter or any character > > between 160 and 255. > > > > And is it defined anywhere, that months names should be only 3 chars long? > I'm afraid that standart is more flexible in this... There's no standard. Sorry. Check for 3 chars, see what breaks. Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From timur at com.bat.ru Sun Oct 7 19:04:47 2001 From: timur at com.bat.ru (Timur I. Bakeyev) Date: Sun, 7 Oct 2001 21:04:47 +0200 Subject: vfs.c "Could not parse" In-Reply-To: ; from proski@gnu.org on Sun, Oct 07, 2001 at 05:06:18AM -0400 References: <20011002223204.A87@toy.ucw.cz> Message-ID: <20011007210447.A858@bat.ru> On Sun, Oct 07, 2001 at 05:06:18AM -0400, Pavel Roskin wrote: > > > > what about checking its three letters and if so, return ok but set date > > to 1970-01-01 to indicate date is wrong? > > Sound good to me. "Letters" should mean any ASCII letter or any character > between 160 and 255. > And is it defined anywhere, that months names should be only 3 chars long? I'm afraid that standart is more flexible in this... The second question is that ls on different platforms can produse much more fields, than expected... Unfortunately, I can't find any examples just now, but sure, they exist:) With regards, Timur. From kai at cmail.ru Mon Oct 8 17:43:44 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Mon, 8 Oct 2001 20:43:44 +0300 (EEST) Subject: Make Solaris door file support more consistent Message-ID: <200110081743.f98HhiQ00684@sav.it.efp.com.ua> Hi! This patch makes recently applied patch for Solaris door file some more consistent. Regards, Andrew. ChangeLog: util.c (string_perm) [S_IFDOOR]: Add support for Solaris door file. screen.c (string_file_type): Likewise. Index: util.c =================================================================== RCS file: /cvs/gnome/mc/src/util.c,v retrieving revision 1.53 diff -u -p -u -p -r1.53 util.c --- util.c 2001/09/11 02:18:02 1.53 +++ util.c 2001/10/08 17:15:23 @@ -360,6 +362,9 @@ char *string_perm (mode_t mode_bits) if (ismode (mode_bits, S_ISVTX)) mode [9] = (mode [9] == 'x') ? 't' : 'T'; if (ismode (mode_bits, S_IFLNK)) mode [0] = 'l'; if (ismode (mode_bits, S_IFIFO)) mode [0] = 'p'; +#ifdef S_IFDOOR + if (ismode (mode_bits, S_IFDOOR)) mode [0] = 'D'; +#endif /* S_IFDOOR */ #endif /* !OS2_NT */ return mode; } --- screen.c Mon Sep 3 16:42:39 2001 +++ screen.c Mon Oct 8 20:39:21 2001 @@ -234,10 +234,16 @@ buffer [0] = '!'; else buffer [0] = '@'; - } else if (S_ISSOCK (fe->buf.st_mode)) - buffer [0] = '='; - else if (S_ISCHR (fe->buf.st_mode)) + } else if (S_ISCHR (fe->buf.st_mode)) buffer [0] = '-'; +#ifdef S_ISSOCK + else if (S_ISSOCK (fe->buf.st_mode)) + buffer [0] = '='; +#endif +#ifdef S_ISDOOR + else if (S_ISDOOR (fe->buf.st_mode)) + buffer [0] = '>'; +#endif else if (S_ISBLK (fe->buf.st_mode)) buffer [0] = '+'; else if (S_ISFIFO (fe->buf.st_mode)) From kai at cmail.ru Tue Oct 16 07:19:16 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 16 Oct 2001 10:19:16 +0300 Subject: [smbfs]: win2k shares can be browsed Message-ID: <20011016101916.A921@sav.it.efp.com.ua> Hi! I applied patch from samba-2.0.7 patchset which fixes some smbfs vs Win2k problem. After this patch win2k shares can be browsed. ChangeLog: * samba/libsmb/clientgen.c (cli_RNetShareEnum): Fix Win2k "out of server memory" error. From samba 2.0.7 patchset. diff -u vfs/samba/libsmb/clientgen.c vfs/samba/libsmb/clientgen.c --- vfs/samba/libsmb/clientgen.c Thu Nov 11 13:36:03 1999 +++ vfs/samba/libsmb/clientgen.c Wed Apr 26 09:06:54 2000 @@ -618,12 +618,16 @@ pstrcpy(p,"B13BWz"); p = skip_string(p,1); SSVAL(p,0,1); - SSVAL(p,2,0xFFFF); + /* + * Win2k needs a *smaller* buffer than 0xFFFF here - + * it returns "out of server memory" with 0xFFFF !!! JRA. + */ + SSVAL(p,2,0xFFE0); p += 4; if (cli_api(cli, param, PTR_DIFF(p,param), 1024, /* Param, length, maxlen */ - NULL, 0, 0xFFFF, /* data, length, maxlen */ + NULL, 0, 0xFFE0, /* data, length, maxlen - Win2k needs a small buffer here too ! */ &rparam, &rprcnt, /* return params, length */ &rdata, &rdrcnt)) /* return data, length */ { From proski at gnu.org Tue Oct 16 07:42:29 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 16 Oct 2001 03:42:29 -0400 (EDT) Subject: [smbfs]: win2k shares can be browsed In-Reply-To: <20011016101916.A921@sav.it.efp.com.ua> Message-ID: Hello! > I applied patch from samba-2.0.7 patchset which > fixes some smbfs vs Win2k problem. > After this patch win2k shares can be browsed. Thank you! I've made the snapshot with it. > ChangeLog: > * samba/libsmb/clientgen.c (cli_RNetShareEnum): Fix Win2k > "out of server memory" error. From samba 2.0.7 patchset. If you are familiar with Samba maybe you could ask them to make a "real" shared library with documented interface? I'm sure there are more changes in Samba that would be useful in MC, but updating the code by hand is perhaps not the best solution in the long term. Another problem that would be solved is that the samba library in MC and system installed Samba don't always share configuration files and actually may _need_ different configuration files (because the Samba versions are different). -- Regards, Pavel Roskin From kai at cmail.ru Tue Oct 16 10:44:57 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 16 Oct 2001 13:44:57 +0300 Subject: [smbfs]: win2k shares can be browsed In-Reply-To: References: <20011016101916.A921@sav.it.efp.com.ua> Message-ID: <20011016134457.A5396@sav.it.efp.com.ua> Hello! > If you are familiar with Samba maybe you could ask them to make a "real" > shared library with documented interface? I am thinking about. > I'm sure there are more changes > in Samba that would be useful in MC, but updating the code by hand is > perhaps not the best solution in the long term. Sure! > Another problem that would be solved is that the samba library in MC and > system installed Samba don't always share configuration files and actually > may _need_ different configuration files (because the Samba versions are > different). One of my long-term goals is a plugged-in VFS'es. And shared samba lib and rewritten sbmfs are first target. But smbclient based extfs is also wanted feature. Regards, Andrew. From kai at cmail.ru Wed Oct 17 12:30:14 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 17 Oct 2001 15:30:14 +0300 Subject: libsamba shared library request. References: <20011017115402.BD0F44D3B@lists.samba.org> Message-ID: <3BCD79D6.5E7970B8@cmail.ru> Hi! What about libsamba shared library like smbwrapper but without wrapping libc function. I want to rewrite Midnight Commander smbfs, and it is wrong way to track and commit all of useful changes from your great project. This shared library will need well documented api in feature (ASAP) and something like samba.h with function declarations. It seems it will be not too hard. It can be based on existed smbwrapper with #ifdef'ed libc function stubs. Please, make cc: kai at cmail.ru There are too many messages in the list. Regards, Andrew. From kai at cmail.ru Wed Oct 17 12:47:28 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 17 Oct 2001 15:47:28 +0300 Subject: --with-samba problems References: <20011017115402.BD0F44D3B@lists.samba.org> <3BCD79D6.5E7970B8@cmail.ru> Message-ID: <3BCD7DE0.1EE484E0@cmail.ru> Hi, Pavel! : : If you configure samba-2.2.1a with "--with-smbwrapper", then you get : smbwrapper.so : : Now, if you rename smbwrapper.so to libsmbwrapper.so and link mc against : it instead on the code from vfs/samba, only few symbols are unresolved: : : from vfs/smbfs.c: : DEBUGLEVEL smb_len smb_buf : : from libsmbwrapper.so: : real_llseek real_lstat64 real_readdir64 real_fstat64 real_stat64 : real_pwrite real_pread Well, yesterday I compiled smbwrapper.so from samba 2.0.7 on glibc 2.1.3 based Slackware 7.1 and linked mc against it. I needed to comment some defines for large file functions because I have not off64_t and stat64 types but samba's configure did not check it. Too old samba version to report, I think. But it is wrong move because smbwrapper.so wrap libc's open, create, write and so on, and it is not that we need. BTW url syntax for smbfs (and maybe ftpfs) must be expanded to allow specify current session language/codeset. I will write to samba at lists.samba.org. Wish me a good luck ;-) Regards, Andrew. From proski at gnu.org Thu Oct 18 05:29:56 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 18 Oct 2001 01:29:56 -0400 (EDT) Subject: Make Solaris door file support more consistent In-Reply-To: <200110081743.f98HhiQ00684@sav.it.efp.com.ua> Message-ID: Hello! > This patch makes recently applied patch for Solaris door file > some more consistent. Thank you. Actually, I also made a similar patch that actually goes a bit further and disables viewing and editing of "doors". It turns out that it doesn't save the viewer from hanging, so further changes are needed. I'm going to remove any special handling of sockets, pipes, character and block devices etc except for the purpose of displaying and sorting them. There is no reason why the viewer is allowed to view character devices but not pipes (see load_view_file). I'm going to disable viewing and editing of anything but regular files. MC is not designed to handle even block devices, let alone pipes. There is no way to interrupt the internal viewer is it gets stuck in open() on a pipe or allocates too much memory for your /dev/hda. This may change, but it's unsafe now. The necessary patches will be applied soon. -- Regards, Pavel Roskin From despair at sama.ru Thu Oct 18 06:23:51 2001 From: despair at sama.ru (Walery Studennikov) Date: Thu, 18 Oct 2001 11:23:51 +0500 Subject: question to maintainers Message-ID: <000701c1579d$74606180$0300000a@srvmain> Hello. I'm asking maintainers about my patch, that adds support for multiple editors and multiple viewers at once, that has been posted a MONTHS ago. This patch was extensively tested by me and I use its benefits every day. Also that was reports that it works very well for other people. This patch almost does not affect stability of MC if its features are not used by users. I'm wondered why there is no single report about this patch from maintainers at all. Still. Even no report that they have seen it. I can imagine two possible reasons for that: 1) They have no time at all to apply and test this. In this case I can supply some screenshots ;) 2) They think that this feature is not useful and even harmful. Well, in this case they have to argue their POVs. (Also MC are used by too many people, so its future cannot be controlled by its maintainers exclusively, according to only their POVs.) -- Regards, Walery From proski at gnu.org Thu Oct 18 08:38:26 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 18 Oct 2001 04:38:26 -0400 (EDT) Subject: question to maintainers In-Reply-To: <000701c1579d$74606180$0300000a@srvmain> Message-ID: Hello! > I'm wondered why there is no single report > about this patch from maintainers at all. Still. > Even no report that they have seen it. > I can imagine two possible reasons for that: > > 1) They have no time at all to apply and test this. That's partly true. I have been busy last days. However, I would apply a patch that is well documented (I mean the technical side - what is changed and why). Since your patch is very important, I suggest that you post the explanation of the implemenation to the list, so that everybody can read and comment it, not just those who have time to download and unzip files from your site and then examine all your code. > In this case I can supply some screenshots ;) I'm more interested in the portability and the quality of the code. If you add "Shift-Ins" to the menu, but it only works on one terminal (Linux console), it will be confusing to everybody else. > 2) They think that this feature is not useful and even harmful. Not at all. The _implementation_ may be harmful if it's buggy, confusing to users or causes portability problems that cannot be easily solved. > Well, in this case they have to argue their POVs. I actually wrote you about the other part of the patch. I have never seen the part responsible for multiple viewers and editors (I mean the separated part). -- Regards, Pavel Roskin From despair at sama.ru Thu Oct 18 09:03:39 2001 From: despair at sama.ru (Walery Studennikov) Date: Thu, 18 Oct 2001 14:03:39 +0500 Subject: question to maintainers References: Message-ID: <001601c157b3$c7c67880$0300000a@srvmain> > Since your patch is very important, I suggest that you post the > explanation of the implemenation to the list, so that everybody can read > and comment it, not just those who have time to download and unzip files > from your site and then examine all your code. This patch is too big to post it uncompressed. But I can do it if you want. Or you mean posting only key ideas ? -- Regards, Walery From proski at gnu.org Thu Oct 18 09:40:33 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 18 Oct 2001 05:40:33 -0400 (EDT) Subject: question to maintainers In-Reply-To: <001601c157b3$c7c67880$0300000a@srvmain> Message-ID: On Thu, 18 Oct 2001, Walery Studennikov wrote: > > Since your patch is very important, I suggest that you post the > > explanation of the implemenation to the list, so that everybody can read > > and comment it, not just those who have time to download and unzip files > > from your site and then examine all your code. > > This patch is too big to post it uncompressed. > But I can do it if you want. > Or you mean posting only key ideas ? Just post the ideas. -- Regards, Pavel Roskin From proski at gnu.org Sat Oct 20 03:58:59 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 19 Oct 2001 23:58:59 -0400 (EDT) Subject: FYI: Fix for fish upload Message-ID: Hello! I noticed that the upload on the fish filesystem stopped working some time ago. It turned out that the call to command() in file_store() used variable of type off_t (64-bit if large files are enabled) with the "%d" format. Declaring command() with gcc __attribute__ would make this problem visible much earlier. I'm going to add __attribute__ whenever possible. I'm afraid that the fish upload is broken in mc-4.5.55 on alpha and other 64-bit architectures even in the default configuration. Now it should be fixed. For now, the maximum file size for fish uploads on 32-bit systems is limited to 16 terabytes. Should be enough for everybody. Even that may be too much if "dd" on the other end is 32-bit (i.e. is limited to 4 gigabytes). The patch has been committed and the snapshot has been uploaded. -- Regards, Pavel Roskin From arysin at yahoo.com Sat Oct 20 18:52:13 2001 From: arysin at yahoo.com (Andy Rysin) Date: Sat, 20 Oct 2001 11:52:13 -0700 (PDT) Subject: Midnight Commander within console in UTF-8 mode Message-ID: <20011020185213.69728.qmail@web11501.mail.yahoo.com> Hi all, I've been trying to run MC under console in UTF-8 mode and MC breaks in some places displaying non-latin symbols. I've tried it with xterm and konsole, putting $ export LC_ALL=uk_UA.UTF-8 $ echo -en "\\033%G" after these two commands console works just fine with any symbols but MC have some glitches. I'm using MC-4.5.55 under Mandrake 8.1. Sincerely, Andriy P.S. snapshot example is attached __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: shot_utf8.png Type: image/png Size: 20063 bytes Desc: shot_utf8.png URL: From proski at gnu.org Mon Oct 22 05:17:19 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 22 Oct 2001 01:17:19 -0400 (EDT) Subject: Midnight Commander within console in UTF-8 mode In-Reply-To: <20011020185213.69728.qmail@web11501.mail.yahoo.com> Message-ID: Hello, Andy! > I've been trying to run MC under console in UTF-8 mode and MC breaks > in some places displaying non-latin symbols. > I've tried it with xterm and konsole, putting > $ export LC_ALL=uk_UA.UTF-8 > $ echo -en "\\033%G" > > after these two commands console works just fine with any symbols but > MC have some glitches. > I'm using MC-4.5.55 under Mandrake 8.1. I believe that we should to make sure first that "ls -l" works correctly under the same conditions. It would be wrong to fix in MC problems that are not MC-specific. It's very well possible that there is more than one problem, so it's important to separate them. Secondly, MC has absolutely no support to the characters of variable lenght. With UTF-8, you can have 2 bytes representing one character, which can be as wide as one or two latin characters (the later is unlikely in Ukrainian, by may happen e.g. in Japanese). MC assumes that one byte is one character wide (see e.g. name_trunc in src/util.c). Correcting this assumption will require significant efforts. Patches are welcome, as usually. Another smaller problem is that the hints are always displayed in the same encoding. It could be fixed by translating the hint files into UTF-8 and translating them to the currently used encoding at runtime. -- Regards, Pavel Roskin From arysin at yahoo.com Mon Oct 22 06:18:32 2001 From: arysin at yahoo.com (Andy Rysin) Date: Sun, 21 Oct 2001 23:18:32 -0700 (PDT) Subject: Midnight Commander within console in UTF-8 mode In-Reply-To: Message-ID: <20011022061832.576.qmail@web11508.mail.yahoo.com> Hello, Pavel! --- Pavel Roskin wrote: > > I've been trying to run MC under console in UTF-8 mode and MC > breaks > > in some places displaying non-latin symbols. > > I've tried it with xterm and konsole, putting > > $ export LC_ALL=uk_UA.UTF-8 > > $ echo -en "\\033%G" > > > > after these two commands console works just fine with any symbols > but > > MC have some glitches. > > I'm using MC-4.5.55 under Mandrake 8.1. > > I believe that we should to make sure first that "ls -l" works > correctly > under the same conditions. It would be wrong to fix in MC problems > that > are not MC-specific. It's very well possible that there is more > than one > problem, so it's important to separate them. I mentioned that, but probably I should be more specific - in this mode console commands work just fine. All the "ls -l", "date" work fine and display all set of symbols for current locale OK, and when I try to do "more utf8.txt" it's just fine as well, and the file is in UTF-8 mode. Console itself does all (well, most :) tricks to keep UTF-8 display correctly. MC does show some (e.g. cyrillic) symbols but others just break it somehow. > Secondly, MC has absolutely no support to the characters of > variable > lenght. With UTF-8, you can have 2 bytes representing one > character, > which can be as wide as one or two latin characters (the later is > unlikely > in Ukrainian, by may happen e.g. in Japanese). MC assumes that one > byte > is one character wide (see e.g. name_trunc in src/util.c). Actually all non-ASCII (incl. cyrillic) symbols take 2 bytes in UTF-8 or even 2-3-... in Korean, Japaneese etc. I don't know how much output of console and MC differ but the code can always be borrowed as far as it's GPL. May be this is more the issue with Curses library and less with MC itself. But if the world is moving to Unicode this should be done somehow. > Correcting this assumption will require significant efforts. > Patches are > welcome, as usually. I would gladly participate in MC development but it would take pretty much time to get into it and I can not do that right now. Otherwise - testing, translating... I'm at your service. > Another smaller problem is that the hints are always displayed in > the same > encoding. It could be fixed by translating the hint files into > UTF-8 and > translating them to the currently used encoding at runtime. That's what for example KDE team succesfully implemented - all translated messages are in UTF-8. But anyway I agree - it's not the main problem. I can't live w/out MC and that's the only thing that stops me turning completely to UTF, I just got enough of all those pesky encodings (especially cyrillic set). Take care, Andriy __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From proski at gnu.org Mon Oct 22 07:51:04 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 22 Oct 2001 03:51:04 -0400 (EDT) Subject: Midnight Commander within console in UTF-8 mode In-Reply-To: <20011022061832.576.qmail@web11508.mail.yahoo.com> Message-ID: > I mentioned that, but probably I should be more specific - in this > mode console commands work just fine. All the "ls -l", "date" work > fine and display all set of symbols for current locale OK, and when I > try to do "more utf8.txt" it's just fine as well, and the file is in > UTF-8 mode. Console itself does all (well, most :) tricks to keep > UTF-8 display correctly. Just in case, make sure that the symbols that are shown as dotted squares are shown correctly. Run "ls -l" in that directory, capture its output and examine it in "more". For comparison try "less", which is linked to ncurses. > MC does show some (e.g. cyrillic) symbols but others just break it > somehow. My guess is that MC is most likely not responsible for that. You could check how the screen library (included S-Lang, system installed S-Lang, ncurses) affects this behavior. Also you could look into "Options->Display bits..." in MC and make sure that you have "Full 8 bits output" enabled. You could also describe your environment better so that I could try it for you. I cannot even get "ls -l" to work properly. What version of KDE and Konsole are you using? What is the locale setting to "konsole" (i.e. what does "locale" show when you just run "konsole")? Do you have the same effect with xterm? What version? > > in Ukrainian, by may happen e.g. in Japanese). MC assumes that one > > byte > > is one character wide (see e.g. name_trunc in src/util.c). > Actually all non-ASCII (incl. cyrillic) symbols take 2 bytes in UTF-8 > or even 2-3-... in Korean, Japaneese etc. > I don't know how much output of console and MC differ but the code > can always be borrowed as far as it's GPL. May be this is more the > issue with Curses library and less with MC itself. > But if the world is moving to Unicode this should be done somehow. I'm afraid that you missed my point. The problem is not the the MC code "differs" from something else. The problem that that the code makes a wrong assumption that one byte occupies one character cell. I don't think there is anything that can be borrowed from the programs that don't care much about the layout of their output on the screen (such as "ls" and "date"). The right solution would be using mbswidth() (from gettext) instead of strlen() to calculate the lenth of the strings on the screen. There are also places in MC where is splits strings at a certain point. It should be ensured that the split is only done at the multibyte character boundaries. Implementation of name_trunc() would be very non-trivial. The worst thing is that it can affect the performance. > I can't live w/out MC and that's the only thing that stops me turning > completely to UTF, I just got enough of all those pesky encodings > (especially cyrillic set). Either you or somebody else fixes MC or you should make some workarounds. First of all, don't use LC_ALL - it cannot be overridden by other locale variables. Use LANG instead. Set LC_TIME and LC_MESSAGES to "C" either globally or for MC only. Use external UTF-8 aware viewer and editor. This will help you "survive" until MC supports multibyte characters. -- Regards, Pavel Roskin From rneri at libero.it Mon Oct 22 07:10:33 2001 From: rneri at libero.it (rneri at libero.it) Date: Mon, 22 Oct 2001 09:10:33 +0200 Subject: Bug report: missing NTFS entries Message-ID: Hi, I would like to report a bug in MC 4.5.51: accessing a local NTFS partition, the last subdirectory and the last file (in alphabetical order) of each directory are missing, no matter which sort order is selected. Regards Roberto Neri From proski at gnu.org Mon Oct 22 08:09:20 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 22 Oct 2001 04:09:20 -0400 (EDT) Subject: Bug report: missing NTFS entries In-Reply-To: Message-ID: Hello! > I would like to report a bug in MC 4.5.51: accessing a local NTFS > partition, the last subdirectory and the last file (in alphabetical > order) of each directory are missing, no matter which sort order is > selected. You forgot to mention the operating system you are using. Please make sure that "ls" (or "dir" if you are on Windows) shows those files, otherwise it's not a problem with MC. Please describe what happens if you are using sort by size. Also please try version 4.5.55 - it should be more stable. -- Regards, Pavel Roskin From kai at cmail.ru Mon Oct 22 08:40:55 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Mon, 22 Oct 2001 11:40:55 +0300 Subject: Bug report: missing NTFS entries References: Message-ID: <3BD3DB97.782AF6D7@cmail.ru> > Hello! > > > I would like to report a bug in MC 4.5.51: accessing a local NTFS > > partition, the last subdirectory and the last file (in alphabetical > > order) of each directory are missing, no matter which sort order is > > selected. > > You forgot to mention the operating system you are using. > > Please make sure that "ls" (or "dir" if you are on Windows) shows those > files, otherwise it's not a problem with MC. > > Please describe what happens if you are using sort by size. > > Also please try version 4.5.55 - it should be more stable. > It is known bug. I think you are using Linux 2.4.x kernel. In the case you may download 4.5.55 and compile it with large file support (configure --enable-largefile; make). Regards, Andrew. From dmartina at excite.com Mon Oct 22 17:29:47 2001 From: dmartina at excite.com (David Martin) Date: Mon, 22 Oct 2001 10:29:47 -0700 (PDT) Subject: User menu entries in editor not working Message-ID: <7161739.1003771787872.JavaMail.imail@bartok.excite.com> I just installed Mandrake 8.1 and the latest MC snapshot (friday). Most menu entries (like insert Changelog) didn't work. A temporary file was created but no changes got to the edited file. The menu entry to indent C code did work and afterwards all others did work too. cooledit.error was created. If I delete it on the fly, things stop working, and if I "touch cooledit.error" things work again. The other solution I found was to add ... 1>%b 2>%e to the entries in the menu file as issued for the indent C entry. *8-) David _______________________________________________________ http://inbox.excite.com From dmartina at excite.com Mon Oct 22 17:37:49 2001 From: dmartina at excite.com (David Martin) Date: Mon, 22 Oct 2001 10:37:49 -0700 (PDT) Subject: Locale report in "mc -V" Message-ID: <4831928.1003772269584.JavaMail.imail@bartok.excite.com> 2001-09-15 Pavel Roskin ... * cmd.c (guess_message_value): Remove the argument. Adjust all callers. * textconf.c (features): Remove "edition", minor fixes. (version): Don't report the current locale - it's meaningless, especially if ENABLE_NLS is not defined. I've seen nothing about this in the list. Sorry if I missed it; I'm quite bussy these days. Why do you think it's meaningless? If someone wrote it, it should be of some use. As I don't know your reasons I can't argue, but I use this feature quite a lot and I feel that some translators may agree with me. I would like to change the rating to maybe "little use" and have it back. On the other hand I see that localized descriptions are not appropiate for bug reports, but that would be a reason to keep the current locale report, not to hide it. (Bug reports would have to include the output of "LANGUAGE=C mc -V"). *8-) David _______________________________________________________ http://inbox.excite.com From dmartina at excite.com Mon Oct 22 17:18:09 2001 From: dmartina at excite.com (David Martin) Date: Mon, 22 Oct 2001 10:18:09 -0700 (PDT) Subject: Spanish translations update Message-ID: <4943236.1003771089957.JavaMail.imail@bartok.excite.com> Spanish translations update (snapshot from October 19th) *8-) David _______________________________________________________ http://inbox.excite.com -------------- next part -------------- A non-text attachment was scrubbed... Name: es-4.5.99-4.po.bz2 Type: application/octet-stream Size: 25073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: es_ES-4.5.99-4.po.bz2 Type: application/octet-stream Size: 25060 bytes Desc: not available URL: From proski at gnu.org Mon Oct 22 23:30:28 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 22 Oct 2001 19:30:28 -0400 (EDT) Subject: Spanish translations update In-Reply-To: <4943236.1003771089957.JavaMail.imail@bartok.excite.com> Message-ID: Hi, David! > Spanish translations update (snapshot from October 19th) Thanks, applied! -- Regards, Pavel Roskin From proski at gnu.org Tue Oct 23 00:10:56 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 22 Oct 2001 20:10:56 -0400 (EDT) Subject: Locale report in "mc -V" In-Reply-To: <4831928.1003772269584.JavaMail.imail@bartok.excite.com> Message-ID: Hi, David! > (version): Don't report the current locale - it's meaningless, > especially if ENABLE_NLS is not defined. > > I've seen nothing about this in the list. Sorry if I missed it; I'm > quite bussy these days. Sorry is not required. There was nothing in the list on this topic. The issue was indeed very minor. "mc -V" displayed the current value of the LC_MESSAGE locale. Firstly, there is a specialized program, called "locale" that does it. Secondly, mc would show LC_MESSAGE even when gettext support is disabled, which could potentially confuse users - mc says that it's using some locale, but shows English messages. Another problem is that LC_MESSAGE not the only locale category that affects mc - LC_TIME and LC_COLLATE affect it as well. My decision was to make mc only show whether is has i18n support or not. The current locale settings can be shown by "locale". If you have a better idea what "mc -V" should show, your suggestions will be welcome. > Why do you think it's meaningless? If someone wrote it, it should be > of some use. Unfortunately, sometimes it's easier to add new code without caring too much about its correctness than to find the right tool that already exists, "locale" in this case. > On the other hand I see that localized descriptions are not appropiate > for bug reports, but that would be a reason to keep the current locale > report, not to hide it. (Bug reports would have to include the output of > "LANGUAGE=C mc -V"). That's correct, although is most cases the output of "mc -V" can be understood without translation. -- Regards, Pavel Roskin From proski at gnu.org Tue Oct 23 00:36:59 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 22 Oct 2001 20:36:59 -0400 (EDT) Subject: User menu entries in editor not working In-Reply-To: <7161739.1003771787872.JavaMail.imail@bartok.excite.com> Message-ID: Hi, David! > I just installed Mandrake 8.1 and the latest MC snapshot (friday). Most menu > entries (like insert Changelog) didn't work. A temporary file was created > but no changes got to the edited file. The scripting support in mcedit is terrible. _Most_ code doesn't work correctly (except the parts that I already fixed). It appears that most code was never tested. Also, the code is written by somebody with a very poor knowledge of C. Here's the example from edit.h: #ifdef _EDIT_C char *edit_init_error_msg = NULL; #else /* ! _EDIT_C */ extern char *edit_init_error_msg; #endif /* ! _EDIT_C */ The compiler never gets a chance to compare that the type of "edit_init_error_msg" used in edit.c is the same as seen from other files. There are more variables declared this way. The error file is not created on startup. However, if it doesn't exist after the command finishes, it's considered an error. But edit_error_dialog() is disabled if called from edit.c (insane!!!) - that's why you don't see the error message. I'll make another round of cleanups in the editor today. Hopefully it will fix the menu. -- Regards, Pavel Roskin From proski at gnu.org Tue Oct 23 05:59:58 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 23 Oct 2001 01:59:58 -0400 (EDT) Subject: User menu entries in editor not working In-Reply-To: Message-ID: Hello, David! > #ifdef _EDIT_C > char *edit_init_error_msg = NULL; > #else /* ! _EDIT_C */ > extern char *edit_init_error_msg; > #endif /* ! _EDIT_C */ Fixed. It turned out that there was a genuine bug behind this mess. Some errors were not reported. E.g. run mcedit, select File->Open file, select /etc/shadow or /dev/null or even /foo/bar - you won't see an error. The reason is because all errors in edit.c were "scheduled" to be displayed at some point which wasn't guaranteed to be reached :-) > I'll make another round of cleanups in the editor today. Hopefully it > will fix the menu. Yes, adding changelogs works now. Missing error file in not considered an error anymore. The new snapshot is uploaded. I appreciate your testing and hope that you will find more bugs :-) -- Regards, Pavel Roskin From kai at cmail.ru Tue Oct 23 13:15:57 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 23 Oct 2001 17:15:57 +0400 Subject: Syntax highlighting documentation request Message-ID: <200110231315.f9NDFvT15228@cmail.ru> It wiil be fine to have more consistent documentation for syntax files. There is no one word about [] and {} in mcedit manual reference, include command is not documented, cooledit regular expression is not described. -- Regards, Andrew. ____________________________________________ ????? ? ??????? ? ???????? ?? InstantChess.com! Play chess on InstantChess.com ! www.instantchess.com From arysin at yahoo.com Wed Oct 24 03:45:44 2001 From: arysin at yahoo.com (Andy Rysin) Date: Tue, 23 Oct 2001 20:45:44 -0700 (PDT) Subject: Midnight Commander within console in UTF-8 mode In-Reply-To: Message-ID: <20011024034544.91506.qmail@web11504.mail.yahoo.com> Hello Pavel! --- Pavel Roskin wrote: ... > My guess is that MC is most likely not responsible for that. You > could > check how the screen library (included S-Lang, system installed > S-Lang, > ncurses) affects this behavior. Also you could look into > "Options->Display bits..." in MC and make sure that you have "Full > 8 bits > output" enabled. 8 bits are defenitely turned on, and I'll try to play with those libraries soon. > You could also describe your environment better so that I could try > it for > you. I cannot even get "ls -l" to work properly. What version of ... I am using Mandrake 8.1: linux-2.4.12, glibc-2.2.4, KDE 2.2.1, XFree 4.1.0, mc-4.5.55 two commands to try: $ export LC_ALL=ru_RU.UTF-8 $ echo -en "\\033%G" First one forces console to display dates in russian with UTF-8 encoding (BTW "LANG" won't do that), and second will force console program to display UTF-8 output correctly (you'll need unicode font). Then if you type 'ls -l' all the dates will be displayed correctly in russian. Again if you do "more utf8.txt" where utf8.txt is text file in UTF-8 it will be displayed correctly. With xterm you should use option "-u8" . From `man xterm`: ( -u8 This option sets the encodingMode resource as ``utf8'', which makes xterm interpret incoming data as UTF-8. You will need a Unicode font. This mode is default under UTF-8 locales. This sets wideChars as a side-effect. Note that +u8 is obsolete. See -8, -en, and -lc also. ) > The right solution would be using mbswidth() (from gettext) instead > of > strlen() to calculate the lenth of the strings on the screen. > > There are also places in MC where is splits strings at a certain > point. > It should be ensured that the split is only done at the multibyte > character boundaries. Implementation of name_trunc() would be very > non-trivial. The worst thing is that it can affect the > performance. That's a real conversation! :) name_trunc() might get more complex but not hopeless. UTF-8 is stable encoding, every byte which is not the beginning of the symbol has got 8th bit set. So if we break on it, just go couple of bytes back to find the beginning. As to performance, in the worst case average length of the panel is ~ 300-400 files which would not be that hard for Pentium to make couple more instructions. Escpecially if we take to account that visual part is not more than 30-40 file names. > Either you or somebody else fixes MC or you should make some > workarounds. I just give the idea and some initial data, if there's nobody to get involved with this now, in some time I'll get back and try to put my hands on it (I'm afraid though that at that time computers won't be something we see them now :)). I just thought that it'd be faster if someone with his hands on MC already sees it helpful and implement it. ... > This will help you "survive" until MC supports multibyte > characters. I can live with single-byte encoding locales now, it's just that we have to move on... Take care, Andriy __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From mc at listserv.bat.ru Wed Oct 24 11:48:21 2001 From: mc at listserv.bat.ru (Timur I. Bakeyev) Date: Wed, 24 Oct 2001 13:48:21 +0200 Subject: Midnight Commander within console in UTF-8 mode In-Reply-To: <20011024034544.91506.qmail@web11504.mail.yahoo.com>; from arysin@yahoo.com on Tue, Oct 23, 2001 at 08:45:44PM -0700 References: <20011024034544.91506.qmail@web11504.mail.yahoo.com> Message-ID: <20011024134821.A3890@bat.ru> I guess it's not an urgent problem and with upcoming glib 1.4 we'll get nice unicode module, so we can be independent from platform and have a better framework to deal with different charsets. I should mention, that MC wasn't(and still not completly) 8-bit clean quite recently - I've commited patches to work with russian filenames and strings in the input less than year ago. And noone complained before :) So, I hope, we can wait a bit untill new version of glib will be released. Also, I don't remember claims that Slang is UTF8 or UCS16 safe.. Regards, Timur. On Tue, Oct 23, 2001 at 08:45:44PM -0700, Andy Rysin wrote: > --- Pavel Roskin wrote: > ... > > My guess is that MC is most likely not responsible for that. You > > could > > check how the screen library (included S-Lang, system installed > > S-Lang, > > ncurses) affects this behavior. Also you could look into > > "Options->Display bits..." in MC and make sure that you have "Full > > 8 bits > > output" enabled. > 8 bits are defenitely turned on, and I'll try to play with those > libraries soon. From ralph.schenn at zurich.com Wed Oct 24 13:19:16 2001 From: ralph.schenn at zurich.com (Ralph Schenn) Date: Wed, 24 Oct 2001 15:19:16 +0200 Subject: Bugs in Release 4.5.54 Message-ID: Hi, i'm using mc 4.5.54 on HP/UX 11.00 (without X, with ncurses) and i have encountered the following Problems: On the left side i had only a list of filenames the right side was in Quick View mode. I was pressing Enter to change directorys and moved the cursor over the list on the left side. After that the program crashed with the following error message and produced a coredump (please look at the backtrace): 1HGLib-ERROR **: could not allocate 118517760 bytesdir 8Delete 9PullDn 10Quit aborting... ${HOME:-.}/.profile[45]: 11145 Abort(coredump) (gdb) bt #0 0xc010e740 in ?? () from /usr/lib/libc.2 #1 0xc00abc94 in ?? () from /usr/lib/libc.2 #2 0xc00ec0dc in ?? () from /usr/lib/libc.2 #3 0xc00ec134 in ?? () from /usr/lib/libc.2 #4 0xc4623bd8 in ?? () from /opt/glib/lib/libglib.sl #5 0xc4623cf4 in ?? () from /opt/glib/lib/libglib.sl #6 0xc4621904 in ?? () from /opt/glib/lib/libglib.sl #7 0x26118 in load_view_file (view=0x7f7ba5fc, filename=0x4 "") at view.c:517 #8 0x263b0 in do_view_init (view=0x40032230, _command=0x0, _file=0x7f7e26b8 "could not allocate 118517760 bytes", start_line=0) at view.c:599 #9 0x265b8 in view_init (view=0x40032230, _command=0x0, _file=0x40031ea8 "sql_010710.tar", start_line=0) at view.c:672 #10 0x2a29c in view_hook (v=0x2) at view.c:2481 #11 0x132b8 in execute_hooks (hook_list=0x0) at util.c:1004 #12 0x16574 in select_item (panel=0x40030300) at screen.c:1588 #13 0x16790 in do_move_up (panel=0x40030300) at screen.c:1660 #14 0x1683c in move_up (panel=0x2) at screen.c:1691 #15 0x17cc0 in panel_callback (h=0x40030050, panel=0x40030300, msg=4, par=259) at screen.c:2345 #16 0x2d988 in dlg_key_event (h=0x40030050, d_key=259) at dlg.c:777 #17 0x2dd48 in dlg_process_event (h=0x40030050, key=2138823644, event=0x7f7e1d78) at dlg.c:905 #18 0x2de44 in run_dlg (h=0x40030050) at dlg.c:938 #19 0x53370 in setup_panels_and_run_mc () at main.c:2191 #20 0x53598 in do_nc () at main.c:2266 #21 0x544e8 in main (argc=1073750784, argv=0x40002300) at main.c:3180 #22 0xc0058f34 in ?? () from /usr/lib/libc.2 I can reproduce this bug if i like. There is also another bug that can be reproduced even more easyly. When you are Tree-Mode and press F3=Forget with the cursor on a directory name the following message appears: 1H** CRITICAL **: file treestore.c: line 549 (tree_store_remove_entry): assertion `ts.check_name != NULL' failed. Nevertheless mc remains for me a very use- and powerfull aplication.... With Greetings from Germany Ralph Schenn From proski at gnu.org Wed Oct 24 17:41:22 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 24 Oct 2001 13:41:22 -0400 (EDT) Subject: Midnight Commander within console in UTF-8 mode In-Reply-To: <20011024134821.A3890@bat.ru> Message-ID: Hello, Timur! > I guess it's not an urgent problem and with upcoming glib 1.4 we'll > get nice unicode module, so we can be independent from platform > and have a better framework to deal with different charsets. Thank you for information! > I should mention, that MC wasn't(and still not completly) 8-bit > clean quite recently - I've commited patches to work with russian > filenames and strings in the input less than year ago. Yes, a lot of cleanup is still needed. > And noone complained before :) So, I hope, we can wait a bit untill > new version of glib will be released. Just to set the record straight. There are several reasons why the problems are not reported to the list, and neighter of them excuses bad programming "because nobody complains": 1) MC has changed the mailing list address twice in the last year. Considering the fact that many people are still using mc-4.5.54 and even mc-4.5.51 (RedHat 7.2 is released with mc-4.5.51), many users may have difficulties finding the new mailing lists. 2) Versions between 4.5 and 4.5.51 were released with so subtle changes between versions, that some users forget to mention the version, assuming that all versions have the same bugs, in other words, assuming that MC is not actively developed. 3) The introduction of the GNOME frontend made some users think that only the GNOME frontend is under development (see for example http://mail.gnome.org/archives/mc-devel/2001-September/msg00001.html). The result is the same - the problems in the text edition are not reported. 4) Many users don't know what is supposed to work. Bugs are often considered limitations. For example, MC supports associating more than one key sequence with the same key, but nobody submitted additional sequences for TERM=xterm assuming that it's not supported. 5) Regarding the bugs in the i18n and 8-bit support, many people affected by them don't speak English sufficiently to ask in this list. > Also, I don't remember claims that Slang is UTF8 or UCS16 safe.. That may be the real problem. S-Lang keeps a table representing the contents of the screen. The version included with MC uses "unsigned short" to keep the character and the attribute, which is not sufficient for Unicode. S-Lang 1.4.4 uses type SLsmg_Char_Type, which is defined to "unsigned short" but can be changed (in theory). On the other hand, ncurses 5.2 comes with "experimental wide-character code": --enable-widec Compile with experimental wide-character code. This makes a different version of the libraries (e.g., libncursesw.so), which stores characters in 16-bits. We provide a simple UTF-8 driver and test program to use this feature with terminals that can display UTF-8. NOTE: applications compiled with this configuration are not compatible with those built for 8-bit characters. You cannot simply make a symbolic link to equate libncurses.so with libncursesw.so -- Regards, Pavel Roskin From proski at gnu.org Thu Oct 25 03:34:36 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 24 Oct 2001 23:34:36 -0400 (EDT) Subject: Bugs in Release 4.5.54 In-Reply-To: Message-ID: Hi, Ralph! > i'm using mc 4.5.54 on HP/UX 11.00 (without X, with ncurses) and i have encountered > the following Problems: Although both bugs are still not fixed, I recommend you to use the latest version 4.5.55. You can find it on http://www.midnightcommander.org/ > On the left side i had only a list of filenames the right side was in Quick View mode. > I was pressing Enter to change directorys and moved the cursor over the list on the left side. > After that the program crashed with the following error message and produced a > coredump (please look at the backtrace): The viewer tries to map the file in memory using mmap() and then resorts to loading the whole file into memory. The later fails if the file is too large. Maybe the configuration script decided that mmap() is broken on your system. Then HAVE_MMAP would not be defined in config.h. You can force MC to use mmap() by giving "--with-mmap" to "configure". The real fix would be to load just parts of the file into the memory. This is also needed on 32-bit platforms with 64-bit file offsets, when the file size exceeds the address space. I'm also considering adding a read-only mode to the editor and using it as the internal viewer. The editor already uses some technique to avoid loading the whole file into the memory. Syntax highlighting in the viewer would be nice too. I'm also considering a more graceful handling of errors. We already discussed in the list how to trap SIGSEGV and SIGBUS in the viewer. > There is also another bug that can be reproduced even more easyly. When you are Tree-Mode > and press F3=Forget with the cursor on a directory name the following message appears: > > 1H** CRITICAL **: file treestore.c: line 549 (tree_store_remove_entry): assertion `ts.check_name != > NULL' failed. This is also present in the current version. I'll have a closer look soon. This shouldn't be _so_ fundamental. -- Regards, Pavel Roskin From franco.bez at web.de Sat Oct 27 12:25:24 2001 From: franco.bez at web.de (Franco Bez) Date: Sat, 27 Oct 2001 14:25:24 +0200 Subject: MC for Win32 revival Message-ID: <01102714252402.00830@scotty> Hi all, I'm planing to revive the M$-Win32 port of the Midnight Commander. During the past few years I did a little Development (based on 4.1.36), and realeased a binary Distribution. (see http://home.a-city.de/franco.bez/mc/mc.html ) The public interest seems quite OK - I have some 170 hits/week, and communication with some 30 active mc-users on Windows (95/98/NT/2000) Currently I'm on the way to merge my changes with the latest mc-source, and try to make mc compile and link with mingw-gcc again. In this context I have a few questions 1. Who else is interrested (or even active) in reviving the Win32 Port ? 1a. Any interrest in building mc with M$-VC++ or Borland C++ (otherwise I will only support mingw-gcc ) 2. mc now uses glib - can anyone tell me (in short - one or two sentences) what this lib is good for ? (I'm trying to decide weather to remove the dependency on glib from MC for Win32, or to merge in the existing win32-glib-port which was done for the GIMP) 3. Being a native german-speaker I found that the german translation has some problems ( broken Hot-keys , translations too long to fit in Dialogs, misleading/unusual translations) Who's currently maintaining the german translation ? So, enough for today Ciao, Franco From scottlockwood at hotmail.com Sat Oct 27 13:04:35 2001 From: scottlockwood at hotmail.com (William Scott Lockwood III) Date: Sat, 27 Oct 2001 08:04:35 -0500 Subject: MC for Win32 revival References: <01102714252402.00830@scotty> Message-ID: YES!!!!! Thank you thank you thank you thank you thank you thank you!!! I have been struggling to get it to compile under Cygwin, and it did, but I can't seem to make it run outside the Cygwin envirnment! ----- Original Message ----- From: "Franco Bez" To: ; Sent: Saturday, October 27, 2001 7:25 AM Subject: MC for Win32 revival Hi all, I'm planing to revive the M$-Win32 port of the Midnight Commander. During the past few years I did a little Development (based on 4.1.36), and realeased a binary Distribution. (see http://home.a-city.de/franco.bez/mc/mc.html ) The public interest seems quite OK - I have some 170 hits/week, and communication with some 30 active mc-users on Windows (95/98/NT/2000) Currently I'm on the way to merge my changes with the latest mc-source, and try to make mc compile and link with mingw-gcc again. In this context I have a few questions 1. Who else is interrested (or even active) in reviving the Win32 Port ? 1a. Any interrest in building mc with M$-VC++ or Borland C++ (otherwise I will only support mingw-gcc ) 2. mc now uses glib - can anyone tell me (in short - one or two sentences) what this lib is good for ? (I'm trying to decide weather to remove the dependency on glib from MC for Win32, or to merge in the existing win32-glib-port which was done for the GIMP) 3. Being a native german-speaker I found that the german translation has some problems ( broken Hot-keys , translations too long to fit in Dialogs, misleading/unusual translations) Who's currently maintaining the german translation ? So, enough for today Ciao, Franco _______________________________________________ Mc-devel mailing list Mc-devel at gnome.org http://mail.gnome.org/mailman/listinfo/mc-devel From miguel at ximian.com Sat Oct 27 19:07:39 2001 From: miguel at ximian.com (Miguel de Icaza) Date: 27 Oct 2001 15:07:39 -0400 Subject: MC for Win32 revival In-Reply-To: <01102714252402.00830@scotty> References: <01102714252402.00830@scotty> Message-ID: <1004209659.6366.1.camel@erandi.ximian.com> > 1. Who else is interrested (or even active) in reviving the Win32 Port ? > 1a. Any interrest in building mc with M$-VC++ or Borland C++ (otherwise I > will only support mingw-gcc ) I would like to see MC running on Windows. Although I am wondering if it is not just trivial to port it using Cygwin? > 2. mc now uses glib - can anyone tell me (in short - one or two sentences) > what this lib is good for ? > (I'm trying to decide weather to remove the dependency on glib from MC for > Win32, or to merge in the existing win32-glib-port which was done for the > GIMP) Hashtables, lists, event loop (which we should probably move to dropping the one we have currently, as it is pretty limited) Miguel From franco.bez at web.de Sat Oct 27 23:09:04 2001 From: franco.bez at web.de (Franco Bez) Date: Sun, 28 Oct 2001 01:09:04 +0200 Subject: MC for Win32 revival In-Reply-To: References: <01102714252402.00830@scotty> Message-ID: <01102801090500.00832@scotty> Am Samstag, 27. Oktober 2001 15:04 schrieb William Scott Lockwood III: > YES!!!!! Thank you thank you thank you thank you thank you thank you!!! I > have been struggling to get it to compile under Cygwin, and it did, but I > can't seem to make it run outside the Cygwin envirnment! Am Samstag, 27. Oktober 2001 21:07 schrieb Miguel de Icaza: > > 1. Who else is interrested (or even active) in reviving the Win32 Port ? > > 1a. Any interrest in building mc with M$-VC++ or Borland C++ (otherwise I > > will only support mingw-gcc ) > > I would like to see MC running on Windows. Although I am wondering if > it is not just trivial to port it using Cygwin? Yes, a cygwin port will be more or less trivial. Cygwin understands automake/autoconf, and also has most posix functions. The problem is that most Windows users want a "native" Windows port. They want to have the drive letters, and all this. I once succeeded building mc-4.1.36 with cygwin, and I didn't like it. Although I love Linux and the bash. But mixing Unix with Windows does cause a lot of headache, and cygwin does this. Most problems occur using cygwin-applications together with "native" Windows Applications. Example : with cygwin you can create symlinks that every cygwin-application understands. But if you try to launch a native Windows Application on such a symlink, this fails. > > 2. mc now uses glib - can anyone tell me (in short - one or two > > sentences) what this lib is good for ? > > (I'm trying to decide weather to remove the dependency on glib from MC > > for Win32, or to merge in the existing win32-glib-port which was done for > > the GIMP) > > Hashtables, lists, event loop (which we should probably move to dropping > the one we have currently, as it is pretty limited) OK - then we should try to use glib also with Windows. Luckyly, glib has already been ported to Windows. > Miguel Ciao, Franco From MStanchin at Home.com Sat Oct 27 20:11:14 2001 From: MStanchin at Home.com (Mark) Date: Sat, 27 Oct 2001 16:11:14 -0400 Subject: MC for the Raq 4i Message-ID: Hi Group, What would it take to get MC on a cobalt raq4i It sure would be nice! Mark From malc at pulsesoft.com Sun Oct 28 00:30:26 2001 From: malc at pulsesoft.com (malc) Date: Sun, 28 Oct 2001 03:30:26 +0300 (MSK) Subject: [PATCH]: aligned file extensions and different sorting mode for .files Message-ID: -- mailto:malc at pulsesoft.com -------------- next part -------------- ? mc.patch ? edit/.deps ? slang/.deps ? src/.deps Index: src/dir.c =================================================================== RCS file: /cvs/gnome/mc/src/dir.c,v retrieving revision 1.27 diff -u -p -r1.27 dir.c --- src/dir.c 2001/09/07 17:52:19 1.27 +++ src/dir.c 2001/10/28 00:25:01 @@ -145,13 +145,21 @@ sort_ext (const file_entry *a, const fil int bd = MY_ISDIR (b); if (ad == bd || mix_all_files){ + if (a->fname[0] == '.' || b->fname[0] == '.') { + if (a->fname[0] == '.' && b->fname[0] == '.') + return sort_name (a, b); /* so they appear at bottom */ + else + return sort_name (a, b) * -reverse; + } else { exta = extension (a->fname); extb = extension (b->fname); + r = string_sortcomp (exta, extb); if (r) - return r * reverse; + return r * reverse; else - return sort_name (a, b); + return sort_name (a, b); + } } else return bd-ad; } Index: src/main.c =================================================================== RCS file: /cvs/gnome/mc/src/main.c,v retrieving revision 1.173 diff -u -p -r1.173 main.c --- src/main.c 2001/10/01 06:51:15 1.173 +++ src/main.c 2001/10/28 00:25:15 @@ -829,6 +829,9 @@ int quiet_quit_cmd (void) return quit; } +/* To align file extensions */ +int align_file_extensions = 1; + /* * Touch window and refresh window functions */ Index: src/main.h =================================================================== RCS file: /cvs/gnome/mc/src/main.h,v retrieving revision 1.27 diff -u -p -r1.27 main.h --- src/main.h 2001/10/23 01:39:25 1.27 +++ src/main.h 2001/10/28 00:25:18 @@ -105,6 +105,7 @@ extern int only_leading_plus_minus; extern int ftpfs_directory_timeout; extern int output_starts_shell; extern int midnight_shutdown; +extern int align_file_extensions; extern char search_buffer [256]; extern char cmd_buf [512]; extern char *cmdline_geometry; Index: src/screen.c =================================================================== RCS file: /cvs/gnome/mc/src/screen.c,v retrieving revision 1.101 diff -u -p -r1.101 screen.c --- src/screen.c 2001/10/01 04:31:49 1.101 +++ src/screen.c 2001/10/28 00:25:32 @@ -169,9 +169,59 @@ add_permission_string (char *dest, int w char * string_file_name (file_entry *fe, int len) { - return fe->fname; +/* start modification */ +#ifdef ALIGN_EXT_2 + char *ext; + int flen, elen; + static char buffer [1000]; /* at most fname len (duh!) */ + + flen = strlen(fe->fname); + ext = extension(fe->fname); + elen = strlen(ext); + + if (fe->fname[0] == '.' || elen == 0) return fe->fname; + memcpy(buffer, fe->fname, flen - elen - 1); + buffer[flen - elen - 1] = 0; + + return buffer; + +#else + if (align_file_extensions == 0) { + return fe->fname; + } else { + + char *ext; + int flen, dlen, elen; + static char buffer [100]; /* at most len */ + + flen = strlen(fe->fname); + dlen = len - (flen - 1); + + if (fe->fname[0] == '.' || dlen <= 0) return fe->fname; + ext = extension(fe->fname); + elen = strlen(ext); + if (elen == 0) return fe->fname; + + memset(buffer, ' ', len); + memcpy(buffer, fe->fname, flen - elen - 1); + memcpy(buffer + (len - elen), ext, elen); + buffer[len] = 0; + + /* end */ + return buffer; + } +#endif } +#ifdef ALIGN_EXT_2 +/* ext */ +char * +string_file_ext (file_entry *fe, int len) +{ + return extension(fe->fname); +} +#endif + /* size */ char * string_file_size (file_entry *fe, int len) @@ -385,6 +435,10 @@ static struct { sortfn *sort_routine; } formats [] = { { "name", 12, 1, J_LEFT_FIT, N_("Name"), 1, string_file_name, (sortfn *) sort_name }, +#ifdef ALIGN_EXT_2 +{ "ext", 3, 1, J_RIGHT, N_("Extension"),1, string_file_ext, NULL + }, +#endif { "size", 7, 0, J_RIGHT, N_("Size"), 1, string_file_size, (sortfn *) sort_size }, { "bsize", 7, 0, J_RIGHT, N_("Size"), 1, string_file_size_brief, (sortfn *) sort_size }, { "type", GT, 0, J_LEFT, "", 2, string_file_type, (sortfn *) sort_type }, Index: src/setup.c =================================================================== RCS file: /cvs/gnome/mc/src/setup.c,v retrieving revision 1.56 diff -u -p -r1.56 setup.c --- src/setup.c 2001/10/01 06:08:57 1.56 +++ src/setup.c 2001/10/28 00:25:35 @@ -156,6 +156,7 @@ static const struct { { "show_backups", &show_backups }, { "show_dot_files", &show_dot_files }, { "verbose", &verbose }, + { "align_file_extensions", &align_file_extensions }, { "mark_moves_down", &mark_moves_down }, { "pause_after_run", &pause_after_run }, { "shell_patterns", &easy_patterns }, From hps at gmx.net Sun Oct 28 11:11:17 2001 From: hps at gmx.net (Hans Peter Stroebel) Date: Sun, 28 Oct 2001 12:11:17 +0100 Subject: MC for the Raq 4i In-Reply-To: References: Message-ID: <01102812111700.08671@yankee> Am Samstag, 27. Oktober 2001 22:11 schrieb Mark: Hi Mark, > Hi Group, What would it take to get MC on a cobalt raq4i > It sure would be nice! The Raq 3i uses a RedHat 6.2-based distribution and AFAIK contains mc. I don`t know what the Raq 4i uses, but it should be RedHat-based, too. Maybe try a normal RedHat rpm package, should install well. -- Hans Peter Str?bel PGP Digital Fingerprint : 74E0 4B50 8B94 C01E D018 23E9 2FEE 11BF 72A4 6C04 sh:# mv --force /bin/laden /dev/null From proski at gnu.org Mon Oct 29 06:11:13 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 29 Oct 2001 01:11:13 -0500 (EST) Subject: MC for Win32 revival In-Reply-To: <1004209659.6366.1.camel@erandi.ximian.com> Message-ID: Hello, Miguel! > > 1. Who else is interrested (or even active) in reviving the Win32 Port ? > > 1a. Any interrest in building mc with M$-VC++ or Borland C++ (otherwise I > > will only support mingw-gcc ) > > I would like to see MC running on Windows. Although I am wondering if > it is not just trivial to port it using Cygwin? Not only is it trivial, but I even tested MC on Cygwin days before releasing 4.5.55 and it compiled with very minor fixes that I committed before the release. MC works quite well on Cygwin, but it sees the system from the UNIX standpoint. It doesn't know about drives and represents permissions in the UNIX form. Another more technical problem was that both editor and the viewer displayed some useless warnings and required some tricks to be used. This may have been a problem with the regex implementation in Cygwin. It could also be caused by the interference between the system regex and the regex implementation included with MC (src/regex.c). The "native" port (as opposed to the trivial Cygwin port) addresses the issues of the drives and the permissions. It also uses the native S-Lang support for the host OS instead of relying on the escape sequences. It supports Win32 and OS/2. Open-sourced EMX and mingw are among the supported compilers. The problem is that the native port is broken and doesn't compile. The makefiles don't know anything about glib. Also the file lists in the makefiles need to be updated. Unfortunately, there has been no interest to the native PC port from the developers ("YES!!!!! Thank you thank you" doesn't count). If I had a working Win32 or OS/2 system around I would probably fix it, but it's not the case. A word of caution. Windows users have a different mentality and don't generally understand the idea of free software. Whoever works on the port may be a subject of spiteful personal e-mail ("you $%$#% program doesn't work") and shameless support requests ("where do I get the fixed binary"). I've had enough of such e-mail just for merging some OS/2 and Win32 code, rewriting the makefiles and minor changes to the code. It is not a big deal if you are prepared, but please _be_ prepared. -- Regards, Pavel Roskin From proski at gnu.org Mon Oct 29 06:54:25 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 29 Oct 2001 01:54:25 -0500 (EST) Subject: [PATCH]: aligned file extensions and different sorting mode for .files In-Reply-To: Message-ID: Hello! Could you please comment your patch? In particular, what's the meaning of ALIGN_EXT_2 and why it's a preprocessor directive rather than a variable that can be changed at the runtime? If it's possible to align extension in the custom mode (which has a half-decent user interface) is it really a good idea to add another undocumented variable that would affect all modes? Most importantly, I don't like the idea of the patch. UNIX filesystem doesn't distinguish extensions and doesn't treat the dot in a special manner. There are conventions (e.g. C files should end with ".c"), but I doesn't want MC users to be fooled by anybody who ignores those conventions. Nothing forbids using dots and spaces in any part of the filename. The following manes are valid: file.ext file .ext file.ext. file ext Aligning the extention may cause some of those filenames to look in exactly the same way on the screen. It is not Ok for a file manager. On the other hand, sorting by extension is Ok because it simply causes the entries to be sorted differently without changing their look. But it's implemeented already. -- Regards, Pavel Roskin From franco.bez at web.de Mon Oct 29 08:21:59 2001 From: franco.bez at web.de (Franco Bez) Date: Mon, 29 Oct 2001 09:21:59 +0100 Subject: MC for Win32 revival Message-ID: <200110290821.f9T8Lxu31612@mailgate5.cinetic.de> Hi Pavel, hi all, > Pavel Roskin schrieb am 29.10.01: > Hello, Miguel! > < ----- cut ----- > > The problem is that the native port is broken and doesn't compile. The > makefiles don't know anything about glib. Also the file lists in the > makefiles need to be updated. > > Unfortunately, there has been no interest to the native PC port from the > developers ("YES!!!!! Thank you thank you" doesn't count). If I had a > working Win32 or OS/2 system around I would probably fix it, but it's not > the case. I already made quite a progress in reactivating the Win32 Port, I added glib (from GIMP for Windows) merged in all my changes, and now all Files (from the Old Makefile ) do compile well. Just the dirent_nt.c is still giving problems: The DIR structure has changed completely, so this file is completely broken. I think that I can make MC compile and link with mingw32 with a few more hours of work. Unfortunately my time is very limited, so this might take a few days/weeks. When I'm finished, this Port will NOT have any new features - especially the VFS is wanting. I will most likely not have the time to activate it myself. But, my hope is that then maybe another developer will jump in and assist. > A word of caution. Windows users have a different mentality and don't > generally understand the idea of free software. Whoever works on the port > may be a subject of spiteful personal e-mail ("you $%$#% program doesn't > work") and shameless support requests ("where do I get the fixed binary"). > > I've had enough of such e-mail just for merging some OS/2 and Win32 code, > rewriting the makefiles and minor changes to the code. It is not a big > deal if you are prepared, but please _be_ prepared. Yes, Windows users are different - at least 99% of them ONLY want a binary Release. But, my personal expirience with support requests and user's "bug"-reports are different. As I already mentioned, I do maintain a binary MC for Win32 release for a few years now, and the feedback is mostly positive. > -- > Regards, > Pavel Roskin Ciao, Franco ________________________________________________________________ Lotto online tippen! Egal zu welcher Zeit, egal von welchem Ort. Mit dem WEB.DE Lottoservice. http://tippen2.web.de/?x=13 From kai at cmail.ru Mon Oct 29 15:45:24 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Mon, 29 Oct 2001 17:45:24 +0200 Subject: --enable-largefile brakes smbfs In-Reply-To: Message-ID: <20011029174524.A18727@bcs.zp.ua> Hi, Pavel! Well, I cannot say smbfs works ok at all, but --enable-largefile brake mc's smbfs. smbfs_readdir returns right filenames but smbfs_(l)stat gets broken ones. There is something wrong with parameters lengths calculation in stack - filename became as filename + 4. It costed me a pretty fish. Another problem with smbfs is not related to LFS. Two first shares cannot be viewed and even more - two first entries in first level directory are substituted by these shares. First entry in these directories has right attributes but a dot instead of its real name. smbfs_readdir returns right one. Regards, Andrew. From proski at gnu.org Mon Oct 29 16:19:45 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 29 Oct 2001 11:19:45 -0500 (EST) Subject: --enable-largefile brakes smbfs In-Reply-To: <20011029174524.A18727@bcs.zp.ua> Message-ID: Hello, Andrew! > Well, I cannot say smbfs works ok at all, but > --enable-largefile brake mc's smbfs. That's why it's not called mc-4.6 yet. > smbfs_readdir returns right filenames but smbfs_(l)stat gets broken ones. > There is something wrong with parameters lengths calculation in stack > - filename became as filename + 4. That's very strange, considering that smbfs_stat only takes pointers. My experience is that debuggers cannot generally be trusted when strange things happen. Only debug printing can be fully trusted. I'm sorry that I'll be very busy during this week, but you are welcome to fix the problem and commit the change, just don't forget to inform the list about it. > It costed me a pretty fish. Sorry for that. > Another problem with smbfs is not related to LFS. > Two first shares cannot be viewed and even more - > two first entries in first level directory are substituted by these > shares. First entry in these directories has right attributes but > a dot instead of its real name. smbfs_readdir returns right one. You can use "--disable-largefile" to check that it's really not related. I would also try different versions of Windows and the latest Samba server. -- Regards, Pavel Roskin From proski at gnu.org Tue Oct 30 07:46:07 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 30 Oct 2001 02:46:07 -0500 (EST) Subject: Going offline, further plans Message-ID: Hello, all! I'll probably be offline during the next few days because I'm moving to New Jersey to start working for AT&T Labs. Don't expect prompt replies from me in the meantime. Sorry for possible inconvenience. Whoever has write access to CVS is encouraged to make commits provided that the explanations are sent to the list. This is my .plan for MC. Sorry, no time to add descriptions, but if you know what it's about, your help is welcome: ================ curses.h not checked for ncurses ncurses and syntax highlighting reimplement "-P" in a safer way (temp file instead of stdout), eliminate use of ~/.mc/tmp integrate RedHat and Debian patches, scan bugzilla cannot change to '~' result of "tar cz" doesn't "look like a tar archive" terminal-dependent settings automatically enable color with S-Lang cannot enter remote RPMs on some systems - always add extention report errors in fish operations - respect $? implement logging ksh support (or universal subshell based on unique cookies in PS1) auto menu broken full path in find file fix exit from subshell in viewer and editor use of is_printable() in the panels separate charset support from character filtering ftpfs reads ../.. for no reason - don't stat ".." force full path to file in mc.ext (needed for gnome-moz-remote, staroffice) - %lf %/f ? copying to fish still causes errors check smbfs+largefile put all fallbacks for socket, fifo, doors into global.h ================ -- Regards, Pavel Roskin From kai at cmail.ru Tue Oct 30 10:19:38 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 30 Oct 2001 12:19:38 +0200 Subject: cpiofs: Buffer overflows and memory leak fixed Message-ID: <20011030121938.A3238@bcs.zp.ua> Hi! This patch was proposed by drk at sgi.com and applied some time ago. I don't know name of this person, but s/he proposed a number of useful patches. Thanks a lot! BTW, I have a number of cpio archives which enforce cpiofs to exit mc. They have old ascii format (CPIO_OLDC, 3), but this one is not handled in cpio_skip_padding and so g_assert_not_reached raises. Old cpiofs without this g_assert_not_reached can manage these archives. CPIO_OLDC is handled in cpio_read_header and cpio_find_header, so I think patch can be trivial. Regards, Andrew. ChangeLog: * cpio.c (cpio_read_crc_head): Fix buffer overflow. (cpio_read_oldc_head): Likewise. By drk at sgi.com. http://bugzilla.gnome.org/show_bug.cgi?id=60933 * (cpio_read_oldc_head): Release name if mc_read fails. --- vfs/cpio.c Mon Mar 5 03:20:03 2001 +++ vfs/cpio.c Thu Oct 25 17:28:04 2001 @@ -300,7 +300,7 @@ if((len = mc_read(super->u.cpio.fd, (void *)buf, HEAD_LENGTH)) < HEAD_LENGTH) return STATUS_EOF; CPIO_POS(super) += len; - buf[HEAD_LENGTH + 1] = 0; + buf[HEAD_LENGTH] = 0; if(sscanf((void *)buf, "070707%6lo%6lo%6lo%6lo%6lo%6lo%6lo%11lo%6lo%11lo", &hd.c_dev, &hd.c_ino, &hd.c_mode, &hd.c_uid, &hd.c_gid, @@ -311,9 +311,10 @@ } name = g_malloc(hd.c_namesize); - if((len = mc_read(super->u.cpio.fd, name, hd.c_namesize)) < hd.c_namesize) + if((len = mc_read(super->u.cpio.fd, name, hd.c_namesize)) < hd.c_namesize) { + g_free (name); return STATUS_EOF; - + } CPIO_POS(super) += len; cpio_skip_padding(super); @@ -348,7 +349,7 @@ if((len = mc_read(super->u.cpio.fd, buf, HEAD_LENGTH)) < HEAD_LENGTH) return STATUS_EOF; CPIO_POS(super) += len; - buf[HEAD_LENGTH + 1] = 0; + buf[HEAD_LENGTH] = 0; if(sscanf(buf, "%6ho%8lx%8lx%8lx%8lx%8lx%8lx%8lx%8lx%8lx%8lx%8lx%8lx%8lx", &hd.c_magic, &hd.c_ino, &hd.c_mode, &hd.c_uid, &hd.c_gid, From kai at cmail.ru Tue Oct 30 12:54:07 2001 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 30 Oct 2001 14:54:07 +0200 Subject: --enable-largefile brakes smbfs In-Reply-To: References: <20011029174524.A18727@bcs.zp.ua> Message-ID: <20011030145407.A25090@bcs.zp.ua> Hello, Pavel! : : > Well, I cannot say smbfs works ok at all, but : > --enable-largefile brake mc's smbfs. : : That's why it's not called mc-4.6 yet. Well, now we are one step closer. Today I fixed this problem and now I understand it was particularly my fault. : That's very strange, considering that smbfs_stat only takes pointers. My : experience is that debuggers cannot generally be trusted when strange : things happen. Only debug printing can be fully trusted. 100 % : You can use "--disable-largefile" to check that it's really not related. : I would also try different versions of Windows and the latest Samba : server. It was really related but I still don't understand how. I will test samba's 2.2.2 smbclient shared library, but it seems it is not trivial keep smbfs.c consistent with external samba's library - samba API is not stable. Regards, Andrew. P.S. Have a fun at new place! Index: smbfs.c =================================================================== RCS file: /home/sav/.cvsroot/mc/vfs/smbfs.c,v retrieving revision 1.27 retrieving revision 1.28 diff -u -p -u -r1.27 -r1.28 --- smbfs.c 14 Aug 2001 00:55:39 -0000 1.27 +++ smbfs.c 30 Oct 2001 12:31:42 -0000 1.28 @@ -21,10 +21,10 @@ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /* Namespace: exports smbfs_vfs_ops */ +#include #include #include -#include #include "utilvfs.h" #include "samba/include/config.h" /* don't load crap in "samba/include/includes.h" we don't use and which From franco.bez at web.de Tue Oct 30 21:07:53 2001 From: franco.bez at web.de (Franco Bez) Date: Tue, 30 Oct 2001 22:07:53 +0100 Subject: MC for Win32 now builds and runs In-Reply-To: <200110290821.f9T8Lxu31612@mailgate5.cinetic.de> References: <200110290821.f9T8Lxu31612@mailgate5.cinetic.de> Message-ID: <01103022075300.05986@scotty> Hi all, today I made a breakthrou. The MC Win32 port now compiles and links with mingw32. And it also runs (tested with Win98 and Win2000) It still has some severe bug(s) that make it go crash when You try to change Directory or Drive. But many things already work (including Find Files, Menues, Dialogs, Info Panel). Now I think that the time would be right for some assistance in debuging. If someone volenteers ;-) I will provide build-instructions and a source-patch soon. Otherwise I'll first try to make the port a little more stable before doing so. Ciao, Franco