Problems with search functionality.

[Theodore Kilgore]

I wrote the message below a couple of weeks ago and did not get around to 
sending it. Since it is still relevant, I send it along with some other 
issues.


-

The F4 (search and replace) routine is not working as it used to do. One 
was (and still one is) presented with a dialog menu which asks various 
things you want to do. Two of these were (and still are)


( ) proMpt on replace
( ) replace All

When running previous versions, I used to be able to tick *both* of these 
choices. Now I can choose only one of them. Any attempt to choose both 
toggles off the one selected first in order to enable the second. :-(


If this has already been noticed and fixed and I should get a more 
up-to-date version, then please let me know.


Theodore Kilgore

---

For some reason, I did not get around to sending this back when I wrote 
it. The problems related to the git version distributed in 
Slackware-current as mc-20090514_git-i486-1 and seem to have been 
perpetuated in the currently-distributed mc-20090621_git-i486-1 package. I 
also have my own git tree for mc. Upon update and recompilation and 
reinstallation yesterday evening, it showed the same symptoms.


In addition to what is described above about the behavior of F4 
search-and-replace functionality while editing with the internal editor, 
there are problems with search while viewing a file with option 
F3. The problems about searching include:


Search is not preserved during one mc session from one file to the next 
(this also is the case if you opened the files with F4 (edit) as well as 
with F3 (view)). If you want to search for the same thing in several 
files, you need to enter the searched-for each time, by hand, in the 
search window every time that you open another file. That is, when you 
closed the first file, you lost any record of what you were searching for 
in it, so when you open the second file and want to search in it for the 
same thing you need to re-type what you are searching for. This 
forgetfulness used not to happen, and it is therefore an unaccustomed 
behavior and an irritating inconvenience. If this was accidental, then I 
hope it is repaired. If the change was deliberate, then might I ask why it 
was done?


Also, to my great amazement and total surprise, I noticed something else 
which appears to me to be a new and retrograde behavior. I think that one 
can easily imagine wanting to search the same file for two different 
things. That is why it is so nice to be able to use F3 (view) and then F7 
to search for, say, foo and then to use / to search for bar. What 
did I find now? That if I tell F4 to search for foo then / is also 
searching for foo and if I open / and ask to search for bar then F4 
will no longer search for foo the next time I open it, but now F4 is 
also searching for bar! In other words, F4 search and / search no 
longer are separate but now are linked together. I hope very much that 
this is unintended behavior, because it appears to me to be a bug which 
impairs the functionality of an old, heavily used, and well loved product.


Is there any reason for these problems, based in some radical revision of 
design philosopy, or are these items merely bugs as I hope they are?




During several attempts to remove and reinstall various versions, another 
problem was unearthed. This one relates to the functioning or 
non-functioning of the option mc -P (exit from Midnight Commander in 
$PWD). There is a script file which needs to be activated. The 
documentation (for example, the man page) says


   -P file, --printwd=file
  Print the last working directory to the  specified  file. 
This
  option  is  not  meant  to be used directly.  Instead, it's 
used
  from a special shell script that automatically changes the 
cur-
  rent  directory  of the shell to the last directory the 
Midnight
  Commander was in.  Source the file /usr/share/mc/bin/mc.sh 
(bash
  and  zsh users) or /usr/share/mc/bin/mc.csh (tcsh users) 
respec-
  tively to define mc as an alias to the appropriate shell 
script.


The problem?

There is no longer any such file as /usr/share/mc/bin/mc.*

Indeed, there is not any directory /usr/share/mc/bin. After some searching 
around, I found the file. It is now in /usr/libexec/mc. Since this change 
is not documented, it is a bit confusing. Also, for the first time in 
years I had to add a line in my .profile file which turns on the ability 
of mc to be exited in $PWD instead of going back to some other place on 
exit. Is this feature supposed to continue to exist without such 
intervention?


Theodore Kilgore
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

new syntax for mc.ext

[Jan Psota]

Could You take a look at this solution for file extension based matching
programs to files? :-)

r.conf -- /etc
r.awk (+x) -- I used to store it in /usr/local/bin
'r.awk -I' will make needed symlinks ('r', 'e' and 'v' for r.conf like
that)

Try with -t, so You will find how it works :-).

What should I change / add to make it good enough to replace mc.ext?
I use mawk, because it is smaller, faster and my GNU awk is broken
-- in line 192 it matches 'e' against /^[A-Z]/ (but not [[:upper:]]).

--
Jan Psota


r.conf
Description: Binary data


r.awk
Description: application/awk

Domeny, serwer, Strona WWW zupelnie za darmo!
Nic nie placisz!
www.nazwa.pl___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[BUG] memory leak in src/file.c::copy_dir_dir()

[Denys Vlasenko]

Hi,

Noticed this memory leak while working on another problem.
Watch variable d:

char *d;

/* First get the mode of the source dir */
  retry_src_stat:
if ((*ctx-stat_func) (s, cbuf)) {
return_status =
file_error (_( Cannot stat source directory \%s\ \n %s ), s);
if (return_status == FILE_RETRY)
goto retry_src_stat;
return return_status;
}

if (is_in_linklist (dest_dirs, s, cbuf)) {
/* Don't copy a directory we created before (we don't want to copy.
   infinitely if a directory is copied into itself) */
/* FIXME: should there be an error message and FILE_SKIP? - Norbert */
return FILE_CONT;
}

d = strutils_shell_unescape (_d);

/* Hmm, hardlink to directory??? - Norbert */
/* FIXME: In this step we should do something
   in case the destination already exist */
/* Check the hardlinks */
if (ctx-preserve  cbuf.st_nlink  1
 check_hardlinks (s, d, cbuf) == 1) {
/* We have made a hardlink - no more processing is necessary */
g_free(d);
return return_status;
}

if (!S_ISDIR (cbuf.st_mode)) {
return_status =
file_error (_( Source \%s\ is not a directory \n %s ), s);
if (return_status == FILE_RETRY)
//bug: leaking d
goto retry_src_stat;
g_free(d);
return return_status;
}


The fix is simple: move g_free(d) up two lines.

Please, can someone with write access do this? Thanks.
--
vda
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: [BUG] memory leak in src/file.c::copy_dir_dir()

[Andrew Borodin]

On Thu, 2 Jul 2009 19:03:30 +0200 Denys Vlasenko wrote:
 Please, can someone with write access do this? Thanks.

Thanks for bugreport.

Ticket have been created.
http://www.midnight-commander.org/ticket/1393

-- 
Andrew
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel