summary refs log tree commit diff stats
path: root/doc/cd-after-exit.txt
blob: 567c20ff727c351c8c83499632be7c5e794b7ff8 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
The "cd-after-exit" Feature

== Abstract

This document explains the troublesome implementation of the "cd-after-exit"
feature.


== Specification

When the feature is enabled, ranger will attempt to change the directory of
the parent shell (from which ranger is run) to the last visited directory
when ranger is exited.

This task is, by its nature, shell dependent.  As a bash or zsh user,
I focused on the implementation for those two shells and left the
addition of support for csh, ksh, and other shells to those who actually use
those shells.


== What's the problem?

Shells have several limitations, the implementation could not be done easily
because:

1. It is not possible to use something like system('cd xyz') at the end.
This command would run in a new shell and wouldn't change the directory
of the parent shell at all.

2. Using exec('cd xyz') is not possible either, since 'cd' is a command
which is directly integrated in to the shell and can not be run this way.


== Redirection of streams

The only way I found is using cd `program` from inside the shell to change
the directory to whatever `program` prints to the stdout:
    
    bash$ cd `echo ..`

Since the user interface still has to be printed, we simply redirect it to
the stderr.  It is not sufficient however to change sys.stdout to sys.stderr,
since curses seems not to be aware of sys.stdout and continues to print out
the interface to the actual stdout.

So what I did was swap the stdout and stderr of the whole ranger process on
the shell command line by using:

    bash$ cd `ranger 3>&1 1>&2 2>&3 3>&-`

Since errors are now printed to the stdout, we have do this in ranger:
    sys.stderr = sys.__stdout__

And at the end, write the current directory to the stdout, which is now
reachable via sys.__stderr__ due to the redirections:
    sys.__stderr__.write(last_visited_directory)

To inform the ranger process about these changes, we add a --cd-after-exit
switch which:
    bash$ cd `ranger --cd-after-exit 3>&1 1>&2 2>&3 3>&-`


== Argument passing

This works well enough, but there are two remaining problems:

1. How to pass arguments to ranger?

2. How to memorize that line? Although you can just copy+paste it
into your bashrc and create an alias, the complexity of the line
could lead to errors.

Both problems are solved by putting the command in a file:

run.sh:
    cd "`ranger --cd-after-exit \"$@\" 3>&1 1>&2 2>&3 3>&-`"

The $@ is responsible for argument passing.  By using the source command,
the file will be evaluated without creating a distinct new shell.

    bash$ source run.sh arg1 ... argN

To add flexibility, replace the name "ranger" in the command to the first
argument.  Now it requires you to pass the name of the ranger command to
the script as the first argument:

run.sh:
    RANGER="$1"
    shift
    cd "`$RANGER --cd-after-exit \"$@\" 3>&1 1>&2 2>&3 3>&-`"


== Put it in a nutshell

I didn't want to have 2 files for the main program and wanted just one
file at /usr/bin/ranger.  So I used this trick to merge both files into one:

    #!/usr/bin/python
    """":
    <shell code>
    """
    <python code>

If you run this file with python, or simply by typing ranger, the program will
run normally.  If you, however, run this file by sourcing it into the shell,
like you did with run.sh, the cd-after-exit mode will be activated.

Now the way of running ranger with the cd-after-exit feature is:

    bash$ source /path/to/ranger.py /path/to/ranger.py

or, if properly installed:

    bash$ source ranger ranger

A convenient way of using this feature is adding this line to your bashrc:

    alias rn='source ranger ranger'


== Open issues

Unfortunately there is some redundancy: you have to type the path to ranger
twice.  I know of no way to fix this, because it is not possible to get the
filename of the file currently being sourced.

Example:

    bash$ echo 'source sourced.sh' > main.sh
    bash$ echo 'echo $0 $@' > sourced.sh
    bash$ bash main.sh
    main.sh

If you find a way to make this print out 'sourced.sh', let me know. :)

Dec 25, 2009
span> Mod1\-l Increase master area size. .TP .B Mod1\-Return Zooms/cycles focused window to/from master area (tiled layouts only). .TP .B Mod1\-Shift\-c Close focused window. .TP .B Mod1\-Shift\-space Toggle focused window between tiled and floating state. .TP .B Mod1\-Tab Toggles to the previously selected tags. .TP .B Mod1\-r Re-applies tagging rules to all windows. .TP .B Mod1\-Shift\-[1..n] Apply .RB nth tag to focused window. .TP .B Mod1\-Shift\-0 Apply all tags to focused window. .TP .B Mod1\-Control\-Shift\-[1..n] Add/remove .B nth tag to/from focused window. .TP .B Mod1\-[1..n] View all windows with .BR nth tag. .TP .B Mod1\-0 View all windows with any tag. .TP .B Mod1\-Control\-[1..n] Add/remove all windows with .BR nth tag to/from the view. .TP .B Mod1\-Shift\-q Quit dwm. .SS Mouse commands .TP .B Mod1\-Button1 Move focused window while dragging. Tiled windows will be toggled to the floating state. .TP .B Mod1\-Button2 Zooms/cycles focused window to/from master area. If it is floating (but not fixed) it will be toggled to the tiled state instead. .TP .B Mod1\-Button3 Resize focused window while dragging. Tiled windows will be toggled to the floating state. .SH CUSTOMIZATION dwm is customized by creating a custom config.h and (re)compiling the source code. This keeps it fast, secure and simple. .SH SEE ALSO .BR dmenu (1) .SH BUGS The status bar may display .BR "EOF" when dwm has been started by an X session manager like .BR xdm (1), because those close standard output before executing dwm. .P Java applications which use the XToolkit/XAWT backend may draw grey windows only. The XToolkit/XAWT backend breaks ICCCM-compliance in recent JDK 1.5 and early JDK 1.6 versions, because it assumes a reparenting window manager. As a workaround you can use JDK 1.4 (which doesn't contain the XToolkit/XAWT backend) or you can set the following environment variable (to use the older Motif backend instead): .BR AWT_TOOLKIT=MToolkit . .P GTK 2.10.9+ versions contain a broken .BR Save\-As file dialog implementation, which requests to reconfigure its window size in an endless loop. However, its window is still respondable during this state, so you can simply ignore the flicker until a new GTK version appears, which will fix this bug, approximately GTK 2.10.12+ versions.