Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix tricks

mmb.pcb.ub.es

Post reply on HN
Print view View original

181–190 of 232 posts

Re: Unix tricks

#181

Post by philsnow »

dspillett wrote: post #158
maw wrote: post #101

Earlier quoted context omitted.

If security isn't a big consideration (read: you control both machines and the network), you go even faster with netcat. On the receiving machine, in its destination directory: nc -l 6789 | tar xvf - And on the sending machine, from its source directory: tar cvf - . | nc receiving-machine 6789 netcat varies a bit from distro to distro, so you may need to adjust these command lines a bit to get it to work.

Add pv (available in many standard repos these days, from http://www.ivarch.com/programs/pv.shtml if not) into the mix and you get a handy progress bar too.

Unless pv has gotten way more magical since the last time I used it, you also need to tell it how many bytes to expect if you want a progress bar.

If it doesn't know how many bytes there will be, it just gives you a "throbber" (which is better than nothing, though).

Re: Unix tricks

#182

Post by philsnow »

vilgax wrote: post #48
crusso wrote: post #20

The special bash command I'm most often asked about by shoulder surfers is !$. It substitutes the last argument in the previous command into the current one. For example: $ ls /some/long/path/somewhere/looking/around/ $ cd !$ cd /some/long/path/somewhere/looking/around/

Better than that for me is "Alt+.", much easier to type. It can be also combined with number like "Alt+2+." will insert second argument. Similarly "Alt+0+." will insert last command. http://linuxcommando.blogspot.in/2009/05/more-on-inserting-a...

In my bash/readline/whatever, Alt++. gives the Nth-from-the-end argument to the previous command. so,

    $ echo a b c d
    a b c d
    $ echo # pressing +.> here inserts 'c', not 'b'.

Re: Unix tricks

#183

Post by jcr »

neoteric wrote: post #94
jcr wrote: post #81

Earlier quoted context omitted.

You are assuming the exact versions of the shell and find programs that you use are the only ones that exist. It may not be a problem on your exact system, but it can be a problem elsewhere.

I am assuming a POSIX-compliant implementation of `find`. The shell is not involved. FWIW, your `find -print0`/`xargs -0` is not POSIX.

Sorry, I didn't see your 'EDIT' caveat when I responded --now that will teach me to reply too soon. ;-)

Also, it seems I failed to be clear; I'm probably too tired I suppose.

My point was there is plenty of ancient and buggy code out there. It could be "most", or even "many" modern unix variants have fixed a lot of the old bugs in find(1), but if you don't have the luxury of working on a current system, and your not allowed to upgrade it, then plenty bad things can happen due to invoking a shell, handling space, quote, and delimiter characters, and so forth.

reference:

  $ uname -a
  OpenBSD alien.foo.test 5.1 GENERIC.MP#207 amd64
setup:

  $ mkdir test
  $ cd test
  $ touch file1
  $ touch file2
  $ touch file3
  $ mkdir ';ls'
bad:

  $ find . -type d -exec sh -c {} \; 
  sh: ./: cannot execute - Is a directory
  ;ls     file1   file2   file3   test.sh
better:

  $ find . -type d -exec sh -ec {} \;
  sh: ./: cannot execute - Is a directory
also bad:

  $ find . -type d -print0 | xargs -0 -r -n 1 -J % sh -c "%"
  sh: ./: cannot execute - Is a directory
  ;ls     file1   file2   file3   test.sh
better:

  $ find . -type d -print0 | xargs -0 -r -n 1 -x -J % sh -ec "%"
  sh: ./: cannot execute - Is a directory
better;

  $ find . -type d -print0 | xargs -0 -r -J % sh -c "%"
best:

  $ find . -type d -print0 | xargs -0 -r -J % sh -ec "%"
POSIX is all great and wonderful in theory, but in practice it's no different than the bogus Java "write once, run anywhere" claim. If a system or utility claims to be POSIX compliant, then you're probably close, but you'll still need to do testing and debugging.

At least some of the issues with find/xargs are mentioned in the following wikipedia article. It's probably more clear than I am right now.

http://en.wikipedia.org/wiki/Xargs

Re: Unix tricks

#184

Post by philsnow »

artagnon wrote: post #143

Feels very outdated. 1. Use zsh, not bash. AUTO_PUSHD, CORRECT_ALL and tons of other options make some tricks redundant. Also, the zle M-n and M-p are more useful than C-r imo. 2. Use tmux, not screen. 3. Use z ( https://github.com/rupa/z ), not j.py. 4. Use cron, not at. Or even systemd timer units, if you're so inclined. 5. Use public-key authentication and keychain, not password-based SSH. 6. Don't send emails fro…

I've given tmux two separate tries and both times it had screen corruption issues with curses apps. screen is tried (and tried, and tried) and true.

I've also invested enough time in learning bash over the years that zsh is not a net-win for me. I've switched to using it on some systems but I seldom use more than what's available in bash. I would switch back to bash on these systems for consistency, but I feel like I've already sunk too much time in to this experiment of using zsh.

don't be a zsh/tmux hipster; there's nothing wrong with "good enough". this lesson has played out several times as businesses / software with arguably better execution / implementation loses out to existing players that have been around a while.

Edit: though, if you're relatively new and haven't been using bash/screen/whatever for decades, I don't think anybody would call you a hipster for using zsh/tmux instead of bash/screen. The marginal utility of learning tmux or zsh is much higher for somebody who hasn't already used other stuff forever.

Re: Unix tricks

#185

Post by philsnow »

growt wrote: post #54

If I may add a trick: ctrl-z - stops a program bg - sends the stopped program to the background fg - gets the program back to the foreground (interactive mode) very useful in editor sessions or when you want to get rid of the endless download/scp that is blocking your terminal

I have my terminal emulator configured to set the URGENT ICCCM hint when it sees a bell character. When I realize a command I just entered is going to take a while, and I want to go look at something else on another workspace, I do this:

    $ alias b='echo -e "\a"'

    $ long_running_thing
    ^Z
    $ fg ; b
    [long_running_thing resumes]
Then when the job completes, the terminal bell will ring and my window manager will get my attention.

Re: Unix tricks

#186

Post by cawel »

pjungwir wrote: post #126
unfletch wrote: post #70

'!!:n' selects the nth argument of the last command, and '!$' the last arg A lot of people know about "!$" (which is shorthand for !!:$), but that's just the tip of Bash's history expansion. I use these things all the time. One of my favorite keystroke savers is adding :h, the head modifier, to !$. For example: $ cp file.txt /some/annoyingly/deep/target/directory/other.txt $ cd !$:h $ pwd # => /some/annoyingly/deep/t…

Another nice ending is `:p` to print the command instead of executing it. I use this if I'm doing something complicated and I want to make sure it's right. Or if I'm saying `!-n:foo` with n>2. Then just up-arrow and enter to run it for real.

Here is a detail when using '!!:n' with ':p' when trying to iteratively construct a complex command. I want to emphasize the use of the up-arrow (which will show the interpolated arguments), as opposed to rewriting exactly what you wrote in the previous command, since the usage of ':p' will be interpreted by the shell as a command in itself:

    $ echo a b c d
    a b c d
    $ echo !!:2:p
    echo b
    $ echo !!:2
    -bash: :2: bad word specifier # there was only 1 argument in last command
However:

    $ echo a b c d
    a b c d
    $ echo !!:2:p
    echo b
    $
     
    $ echo b

Re: Unix tricks

#187

Post by philsnow »

65a wrote: post #58

Here's one it took me a while to figure out... Hung SSH session (such as wifi out of range)? Type Return-Tilde-Period

Also, if you've done this:

    you@somehost:~$ ssh otherhost
    you@otherhost:~$ some_command
If you hit ^Z right now, it will tell the shell on otherhost to stop some_command and give you the shell prompt on otherhost back.

If instead you wanted to stop the ssh process and get the shell prompt on somehost, hit Tilde ^Z (you don't have to hit a new Return, but ssh only notices these escape sequences after a Return).

Also if you use ControlMaster and have a few xterms open all with sshs to otherhost, and then you exit the first ssh you happened to have open, it will seem to hang and not give you your prompt back. What's happening is that that ssh process is the "control master" and it's still open because you've got other sshs to the same host open. Hit Tilde & to background the ssh process and get your terminal back.

Yes, you could also hit Tilde ^Z and then 'bg' the ssh process.

Re: Unix tricks

#188

Post by marvwhere »

i'm working with unix since years, but only on my server, and now for a little bit more then a year now on osx for 2 days a week.

and since one month i have my first own macbook. totally helpful to get in touch with some magic in the console.

thank to everybody, who makes my working life easier =)

Re: Unix tricks

#189

Post by SEJeff »

I can't believe this past has sort | uniq when GNU sort (important distinction, the BSD version and hence OSX can't) has a -u flag so sort -u == sort | uniq

Re: Unix tricks

#190

Post by absqua »

pjungwir wrote: post #126
unfletch wrote: post #70

'!!:n' selects the nth argument of the last command, and '!$' the last arg A lot of people know about "!$" (which is shorthand for !!:$), but that's just the tip of Bash's history expansion. I use these things all the time. One of my favorite keystroke savers is adding :h, the head modifier, to !$. For example: $ cp file.txt /some/annoyingly/deep/target/directory/other.txt $ cd !$:h $ pwd # => /some/annoyingly/deep/t…

Another nice ending is `:p` to print the command instead of executing it. I use this if I'm doing something complicated and I want to make sure it's right. Or if I'm saying `!-n:foo` with n>2. Then just up-arrow and enter to run it for real.

  shopt -s histverify
to show the expanded command before executing it. Then just enter. I never get these right the first time.
Post reply on HN