141–150 of 232 posts
Is there a command/short-cut to storing the path(s) returned from a find command? Currently I do something like: find . -name somefile.txt -print Then copy and paste the results manually into a cd command for example. I feel like there's a much better way somewhere.
Earlier quoted context omitted.
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...
If you are on OS X and use Terminal.app “Alt-.” won’t work because Alt is used for alternate characters. You have two options: enable “use option as meta” in the app settings (but you lose the extra characters) or use “Esc-.” instead. Yes, I know about iTerm. I don’t want it.
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 from command-line naively; you have no control over the headers. Use git-send-email or similar.
7. Consider using something slightly more sophisticated than Python's SimpleHTTPServer to share files/ folders. One example: woof (http://www.home.unix-ag.org/simon/woof.html)
zsh: setopt extendedglob allows you to use numeric ranges on globbing with : mv p1080 .jpg folderx/ to move p1080100.jpg through p1080300.jpg to a new folder. Still not available on bash or more common shells?
Bash: mv p1080{100..300}.jpg folderx/
Earlier quoted context omitted.
re: 4: not only is an ssh agent by far safer, but most agents now allow you to set a timeout on a key, so it's not indefinitely saved in memory. A passwordless key gives anyone with acces to that file, access to the login associated with it. If that file is inadvertently exposed (oops, checked it into github...), any machine you have a login on must be considered compromised.
ssh-agent and 'ssh -A' is also useful if you have to login to one machine to access another, without having to copy your private key to the first machine. For example if you login remotely to a machine, and want to access a git repository on another: $ eval `ssh-agent -s` $ ssh-add ~/.ssh/id_ $ ssh -A you@firstserver$ git clone git+ssh:// /path/to/repository
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
Consider using a dedicated key for each of those circumstances, set sane defaults in your ~/.ssh/config on all machines, and be very careful about what ends up in any of your ~/.ssh/known_hosts files, as they provide a road map to other destinations.
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…
Sad, but I find this is generally the case in extremely large enterprises where there is a mix of AIX, HPUX, Linux and Solaris being used due to years of weird procurement decisions. Sigh.
'ssh -R 12345:localhost:22 server.com "sleep 1000; exit"' forwards server.com's port 12345 to your local ssh port, even if you machine is not externally visible on the net. This one blew my mind
Better to use, e.g.: ssh -fN -o ServerAliveInterval="240" -R 2222:localhost:22 example.com (And on example.com ssh -p 2222 localhost ) This lets you easily keep the tunnel open long-term. Why? -f Background the ssh process (don't need nohup) -N Don't run any command -o... Make ssh do the work of keeping the session alive forever
'sshfs_mount' is not really stable, any network failure will be troublesome'
To avoid trouble with remote backups and other long running processes, I always add the following to the end of ~/.ssh/config or /etc/ssh_config:
Host *
ServerAliveInterval 300Instead of ProxyCommand ssh -T host1 'nc %h %p' you can use ProxyCommand ssh -W %h:%p host1 which uses ssh itself and therefor also works on machines where netcat isn't installed.
'ssh -R 12345:localhost:22 server.com "sleep 1000; exit"' forwards server.com's port 12345 to your local ssh port, even if you machine is not externally visible on the net. This one blew my mind
Better to use, e.g.: ssh -fN -o ServerAliveInterval="240" -R 2222:localhost:22 example.com (And on example.com ssh -p 2222 localhost ) This lets you easily keep the tunnel open long-term. Why? -f Background the ssh process (don't need nohup) -N Don't run any command -o... Make ssh do the work of keeping the session alive forever
Earlier quoted context omitted.
How so? Also, I find that if I'm going to copy the data once, I'm often going to copy it twice, or which to get a more up to date version of it at a later time. Rsync clearly wins in these cases. Finally, from the compress flag on rsync: Note that this option typically achieves better compression ratios than can be achieved by using a compressing remote shell or a compressing transport because it takes advantage of t…
Rsync is brilliant and useful but gets very slow when you apply it outside of its sweet-spot. Remember: Rsync trades CPU and disk i/o ( lots of disk i/o) for network bandwidth. In the pathological case "thousands of tiny files over a fast network" it can easily be orders of magnitude slower than a straight tar.