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

191–200 of 232 posts

Re: Unix tricks

#191

Post by malloc2x »

carlesfe wrote: post #179
malloc2x wrote: post #176

Earlier quoted context omitted.

If that's an issue (I've never met a server like that, not to mention one like that and I couldn't change the setting) then wouldn't you rather use this? while [ true ]; do sleep 1000; done Just using: sleep 1000; exit means you can't make new connections after 17 minutes.

Yes, in fact I use the first one (while true; sleep; ls) but I thought the second is more succint. Anyone interested can make a loop. Please notice that most of the snippets aren't meant to be copied & pasted, but rather analyzed and understood by the user.

Ah, sometimes that's a hard line to draw since often the people that know enough to understand not to take it literally don't really need the pointer in the first place. :)

I enjoyed your list.

Re: Unix tricks

#192

Post by neoteric »

jcr wrote: post #183
neoteric wrote: post #94

Earlier quoted context omitted.

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…

The contrived examples you've shown aren't examples of POSIX-incompatibility, or bugs in `find` at all. You've explicitly involved the shell. Of course trying to run every directory name as a shell command string is going to result in executed code!

Your original argument was that given:

    find . -type d -exec chmod g+x {} ';'
It is possible to force code execution of arbitrary commands given a carefully crafted directory name. The key difference in this case is that the shell is not involved _at all_. I challenge you to find an implementation of `find` that is broken in this way.

As a side note, it is even possible to involve the shell in the picture in a safe way with `find`, without the use of `xargs` (and thus avoid the overhead of setting up a pipeline):

    find . -type d -exec sh -c 'chmod g+x "$1"' _ {} ';'
(my contrived example is quite poor, though, since it does nothing but introduce unnecessary shell overhead)

Modern (POSIX > 2001?) `find`'s support `-exec {} +` which further reduces the number of reasons to invoke `xargs`:

    find . -type d -exec sh -c '
        for x; do
            do_foo "$x"
            do_bar "$x"
            do_baz "$x"
        done
    ' _ {} +
(example above shows how to make proper use of this feature with an explicit shell invocation)

Re: Unix tricks

#193

Post by tedchs »

jofel wrote: post #44

Instead of find . -type d -exec chmod g+x {} \;' you can usually use chmod -R g+X . which gives additionally the group execute permission to files which have already user/everyone execute permission.

Yes, but the find command will only affect directories (-type d).

Re: Unix tricks

#194

Post by jevinskie »

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/

Is there one for all but the first argument?

Re: Unix tricks

#195

Post by lobster_johnson »

jameswyse wrote: post #22
ciupicri wrote: post #3

> SMB is better than NFS. More details would be nice.

I've found NFS to use much less cpu than SMB (on raspberry pis running XBMC at least)

I believe NFS is a less chatty protocol with fewer roundtrips. SMB is not a particularly well-designed protocol overall.

My only evidence is anecdotal. Back in ~1998 we had Samba running on our small Linux file server using Windows NT desktops via 10mbit Ethernet. It was dog slow, not just for browsing but on sequential things like file transfer. We installed NFS mounts on the same box, and it turned out to be lightning fast. I don't remember just how fast, but it made everyone go "wow".

Nowadays, with NFS over fast 100mbps or gigabit Ethernet the latency difference probably is not significant enough to make a difference. I prefer NFS just because its more Unixy.

Re: Unix tricks

#196

Post by bumbledraven »

alexkus wrote: post #121
JoeAcchino wrote: post #21

Earlier quoted context omitted.

3) if all the lines of the 10+GB file are actually unique, wouldn't awk keep the whole file in RAM? For files larger than my RAM could this leave my system unresponsive because it's thrashing on swap?

Yes it will, and a bit (read: a lot) more than 10GB as it needs to store the contents of variable x in a hash table (with the corresponding hash key and value of the counter). There's no other magic way it can 'know' whether a particular line has been seen before. You can't rely on hash keys alone as the hashes aren't guaranteed to be unique. For files with relatively few duplicates it's going to be a lot slower than…

Yes it will ... [need] to store the contents of variable x in a hash table [...] There's no other magic way it can 'know' whether a particular line has been seen before. You can't rely on hash keys alone as the hashes aren't guaranteed to be unique.

Technically that's true, but the result of a cryptographic hash like SHA-256 is (practically) guaranteed to be unique. Depending on the average length of an input line and how many of the lines are unique, storing only the SHA-256 hash value could take far less memory than storing the input lines along with a non-cryptographic 32-bit hash value.

Re: Unix tricks

#197

Post by nonamegiven »

"Add "set -o vi" in your ~/.bashrc to make use the vi keybindings instead of the Emacs ones." Better to do this kind of thing in .inputrc, as:

set editing-mode vi

(or set editing-mode emacs) because any application that uses readline gets to use those settings. So for example you get command line editing in various command line apps. bash uses readline, so you'll get that. The python repl will give command line editing with .inputrc set as above.

  $ apt-rdepends -r libreadline6 |egrep -ve "^ " |wc -l
  8995
psql (postgresql) and mysql (mysql) are really handy with command line editing.

"'ctrl-x ctrl-e' opens an editor to work with long or complex command lines"

If you've set -o vi, or set editing-mode vi in .inputrc, then on a command line type:

  esc-v
(Escape key to get out of insert mode, then the 'v' key) That will open a full vim session for editing your complex command line.

  :wq
exits vim and gives your command to bash to execute.

Re: Unix tricks

#198

Post by pyre »

absqua wrote: post #190
pjungwir wrote: post #126

Earlier quoted context omitted.

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.

In zsh, you can hit to expand it in place before hitting .

Re: Unix tricks

#200

Post by klibertp »

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 would recommend fasd (https://github.com/clvv/fasd) as a more feature complete alternative to z.
Post reply on HN