| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
before, in the search_next method, item.mimetype could be None,
resulting in an exception in lst.sort(key=fnc) when
order == 'mimetype'.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 14412eea0cd7ec556062f8f984dc5577ebdc8b30.
Since rifle now does file-extension-based file type recognition, this
commit is not necessary anymore.
|
|
|
|
|
|
|
|
|
| |
file is unreliable, often simple file-extension based recognition yields
better results.
See:
https://github.com/hut/ranger/issues/44
https://bbs.archlinux.org/viewtopic.php?pid=1147719#p1147719
|
| |
|
|
|
|
|
|
| |
This reverts commit d6c78470ba0e3a9923d5cc13a5babaca4d52aecf.
It makes ... little sense atm to remove this.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code implements the functionality of cp and mv coreutils in python
and was removed as of v1.4.0 for efficiency and simplicity reasons.
I moved it back in for several reasons:
1. I plan to enhance shutil_g to report on its copying status so I can
display a progress bar
2. With no need for external cp/mv programs, distribution-specific
differences (like broken backup option on MacOS/BSD?) become irrelevant
3. You can still copy in ranger if you accidently delete /bin/cp
4. It gets rid of the occasional bug that the cp process keeps running
when ranger is terminated while copying
The possible downside is reduced efficiency in copying and ranger might
get stuck if the copying function is blocked. Let's see if it works
out.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
instead of 's', you can append &>/dev/null
instead of 'p', you can append |less
instead of 'w', you can append ;read
If there is demand, I'll add the flags back in.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
doc/ranger.1
ranger/defaults/apps.py
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
This fixes the bug that some programs are killed even if they were run
with the "d" flag, if ranger is killed by closing its terminal with the
window manager instead of closed with :quit.
|
| | |
|
| | |
|
| |
| |
| |
| | |
https://bbs.archlinux.org/viewtopic.php?pid=1143920#p1143920
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
rough explanation: before, the "t" flag would run the program in a
terminal by prepending something like "xterm -e " to the command.
If the command is "ls | less", it would result in "xterm -e ls | less".
This commit changes it so the result looks more like
"xterm -e sh -c 'ls | less'" and works as intended.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://github.com/hut/ranger/issues/45
hut:
I've been experiencing irregular segfaults in ranger-master for which
I can't figure out the reasons. Here is all the info I got:
- It started around the time of commit 5417dda
- I think it is a problem with curses' addstr/addnstr function
- It happens randomly, there is no specific action that causes it
- It happens more often with python3 than with python2
- It's most likely somewhere in here: git diff master 5417dda5^
ranger/gui/widgets/browsercolumn.py - but I don't see anything
wrong.
hut:
I nailed it down to 93601b1 and fixed it.
For what it's worth, this is how to reproduce it: (tested with
rxvt-unicode 9.15 and dwm but may work with any other tiling window
manager):
- Ensure that the setting display_tags_in_all_columns is set to True
(this is the default)
- Tag a file or directory with the "t" key
- Navigate so that this tagged file is the LAST file you see of a
column other the main column
- Open a new window (resulting in rangers window getting smaller by at
least one row)
- Close a window (resulting in rangers window growing back to the
original size)
- Watch rangers brain being splattered all over the sand
If you don't use a tiling window manager, you can do steps 1-3 and
then resize rangers window very quickly.
When resizing ranger manually, one of these messages is printed
instead of "Segmentation Fault":
- *** glibc detected *** python2.7: corrupted double-linked list: 0x0949cc98 ***
- python2.7: malloc.c:3964: _int_free: Assertion `nextchunk->fd_nextsize->bk_nextsize == nextchunk' failed.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://github.com/hut/ranger/issues/44#issuecomment-7558251
adam8157:
have 10 mkv files, four of them are "application/octet-stream"(and file
without options returns "EBML file, creator matroska"), others are
"video/x-matroska".
|
| | |
|