* 3235_copy_with_special_symbols:
Add '?' sign as a possible mark of wildcard.
Fix for issue:
Ticket #3235: copy files dosn't work as expected, when copying to a directory with the special symbol in its name
When copying to directory with a name containing special symbol "*" the copy command didn't do it in a right way.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
Using the "?" pattern in the file selection dialog brought up with '+',
mc uses the file name length in bytes instead of characters.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
* 2309_shell_patterns:
The patch does not intend to fix all Bash patterns (I believe mc never claimed to support all kinds of them), but it fixes some issues. Namely, backslash-escaped metacharacter like {}*? will remain in the pattern (with the current code it is just stripped). Second, comma will be transformed to | only inside a group.
Ticket #2309: "Shell patterns" broken beyond repair.
Namely, backslash-escaped metacharacter like {}*? will remain in the pattern (with the current code it is just stripped). Second, comma will be transformed to | only inside a group.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
How to reproduce:
Either on the command line, or in any other text entry field (e.g. copy
file to) enter a string where the last word consists of one single
letter only. E.g. "abc de f".
Press Alt+Backspace.
Expected behavior: Remove the last word, that is, the letter "f" only,
leaving "abc de ".
Actual behavior: Yet another word is removed, leaving "abc ".
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
At certain terminal widths (including the default 80), if the last byte
of a line begins a CJK character then the corresponding glyps is drawn
in the last column, so it's replaced by a replacement symbol.
The default layout should, at all possible terminal widths, have an
extra last character column that is empty normally, but allows room for
a CJK to overflow here.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
(mcview_handle_editkey): an is_printable() check was performed for every
byte of the UTF-8 which obviously doesn't make sense. This check
shouldn't be performed for 8-bit charsets either. If the given byte can
arrive as input, the file should be modified accordingly.
The TAB key shouldn't be accepted as literal, to allow moving back to
the hexview area.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
UTF-8 characters show up nicely in the right column (followed by a space
to align with the number of bytes).
However, as soon as you edit the file (either by the hex codes, or by
moving to the right column and entering an UTF-8 character), that
character doesn't show up there.
Expected: during editing the file, the right hand side should
continuously be updated to look exactly as if that was the original
contents of the file.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
When panel is set to 'Quick view' mode, some keys are handled by
mvciewer, and unhandled keys are passed to the command line. This is
very dangerous since user can easily type and execute a harmful command.
1st step:
* (mcview_callback): don't pass any keys from mcviewer in QuickView
mode to the command line.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Prepend value of system-wide PROMPT_COMMAND variable to the mc's one.
Thanks wjaguar for the idea and Serhiy Storchaka and Oswald Buddenhagen
for the patch itself.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Problem:
Suppose you want to replace a substring in some file names with another,
so you do a File Rename operation with source pattern:
*OLDSTRING*
and target pattern:
\1NEWSTRING\2
If OLDSTRING occurs inside a filename, it is replaced correctly, but if
at the beginning or end of the filename, the corresponding zero-length
wildcard match is replaced by literal \1 or \2, respectively.
Expected
Wildcards that match a zero-length substring should be substituted with
an empty string.
Thanks boris<> for the original patch.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
