Sunday·06·October·2013
Searching in Screen’s copy mode //at 23:43 //by abe
I’m using GNU Screen daily for definitely more than a decade and I became maintainer of Debian’s screen package nearly exactly two years ago. Nevertheless it still happens occassionally that I discover features yet unknown to me. Recently I had one of these moments again:
I looked for a specific line in the long output of a command which has run
inside a Screen session. For that I entered Screen’s copy mode with
Ctrl-A [
and scrolled around with arrow keys and page-up
and -down keys.
But didn’t find it. I thought, it would be cool if I can search for
the string I’m looking for. Intuïtively I typed /
,
the search string and pressed enter. And it worked! It jumped to the
next occurrence of that string.
Of course I immediately had to check if tmux has such a feature, too. And it indeed has, but it seems to be a less sophisticated implementation:
Feature | Key-binding in GNU Screen | Key-binding in Tmux |
---|---|---|
Switch into copy/scroll mode (needed for the remainder) |
Ctrl-A [ |
Ctrl-B [ |
Search for string once, forward | / + string + Enter |
Ctrl-S + string + Enter |
Search for string once, backward | ? + string + Enter |
Ctrl-R + string + Enter |
Search for string again, forward | / Enter |
Ctrl-S Enter |
Search for string again, backward | ? Enter |
Ctrl-R Enter |
Incremental search for string, forward | Ctrl-S + string |
- |
Incremental search for string, backward | Ctrl-R + string |
- |
(Incremental) search for next occurrence, forward | Ctrl-S again |
- |
(Incremental) search for next occurrence, backward | Ctrl-R again |
- |
Being able to do incremental search like with GNU Emacs gave me yet
another reason for continuing to use Screen and not to switch Tmux.
;-)
Tagged as: copy mode, feature, GNU Screen, screen, search, tmux
2 comments // show without comments // write a comment
Related stories
Wednesday·02·October·2013
How to make wget honour Content-Disposition headers //at 16:12 //by abe
Download links often point to CGI scripts which actually generate (or
just fetch, i.e. proxy) the actual file to be downloaded, e.g. URLs
like http://www.example.com/download.cgi?file=foobar.txt
.
Most of such CGI scripts send the real file name in the Content-Disposition
header as specified
in the MIME Specification.
All browsers I know (well, at least those I use regularily :-) handle that perfectly and propose the file name sent in the Content-Disposition header as file name for saving the downloaded name which is usually exactly what I want.
All browsers do that, …, just not my favourite commandline download tool GNU Wget … Downloading the above URL with wget would look like this with default settings:
$ wget 'http://www.example.com/download.cgi?file=foobar.txt' --2013-10-02 16:04:16-- http://www.example.com/download.cgi?file=foobar Resolving www.example.com (www.example.com)... 93.184.216.119, 2606:2800:220:6d:26bf:1447:1097:aa7 Connecting to www.switch.ch (www.example.com)|2606:2800:220:6d:26bf:1447:1097:aa7|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2020 (2.0K) [text/plain] Saving to: `download.cgi?file=foobar.txt' 100%[============================================>] 2,020 --.-K/s in 0s 2013-10-02 16:04:24 (12.5 MB/s) - `download.cgi?file=foobar.txt' saved [2020/2020]
Meh!
But luckily Wget can do that, it’s just not enabled by default — because it’s an experimental and possibly buggy feature, at least according to the man page. Well, works for me! :-)
You can easily enabled it by default for either your user or the whole
system by placing the following line in your ~/.wgetrc
or /etc/wgetrc
:
content-disposition = on
Given the CGI script sends an appropriate Content-Disposition header, the above output now looks like this:
$ wget 'http://www.example.com/download.cgi?file=foobar.txt' --2013-10-02 16:04:16-- http://www.example.com/download.cgi?file=foobar Resolving www.example.com (www.example.com)... 93.184.216.119, 2606:2800:220:6d:26bf:1447:1097:aa7 Connecting to www.switch.ch (www.example.com)|2606:2800:220:6d:26bf:1447:1097:aa7|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2020 (2.0K) [text/plain] Saving to: `foobar.txt' 100%[============================================>] 2,020 --.-K/s in 0s 2013-10-02 16:04:24 (12.5 MB/s) - `foobar.txt' saved [2020/2020]
Now Wget does what I mean!
You can also set this as flag on the commandline, but typing
wget --content-disposition …
everytime is surely
not what I want. ;-)
Tagged as: CGI, CLI, Content-Disposition, download, howto, HTTP, Shell, UUUCO, wget
2 comments // show without comments // write a comment