#27

This is the cheatsheet I made for myself, maybe that could help someone.

Primitives

ls List files in the directory
cd Change directory
rm Remove file or directory(-r)
cp Copy file or directory(-r)
mv Move file or directory
wc Count words in file
man Read the manual
cat Reads content of files sequentially
mkdir Make new directory
date Show system date
grep Searches text for matches of a regular expression
tail Displays the tail end of a file or data

Pipes

ls > foo Send output from ls into file foo
wc < foo Receive input from file foo into wc
ls | wc Connect output of ls into input of wc

Options

-a All, Append -n Number
-b Buffer, Batch -o Output
-c Command, Check -p Port
-d Debug, Delete, Directory -q Quiet, Quit
-e Execute, Edit -r Recurse
-f File, Force -s Silent
-g Group -t Tag
-h Headers, Help -u User
-i Interactive -v Verbose, Version
-j -w Width
-k Keep -x Extract
-l List -y Yes
-m Message -z
12 Likes
#28

One of the most useful command line tricks I have ever learned was how to background and foreground programs. If you are running something like vim in the terminal you can press ctrl-z to send it to the background and get you command prompt back. You can then run the fg command to bring it back. Super useful if you are editing a bit of code and want to test it out without opening a new window or quitting out of you text editor.

6 Likes
#29

You can also fire off things to run in the background by adding an ampersand & to the end of your set of commands (piped or otherwise), it will return a PID + job number and will also report when that PID completes/fails/whatever… Also, fg accepts job number as an argument if you have more than one thing backgrounded.

I actually use the vimium extension in chrome so I can use vim shortcuts to browse, great for browsing when i’m on the laptop on the couch and don’t want to use the touchpad.

2 Likes
#30

I found that putting together small bash scripts to solve small problems makes a cool (executable) library of commands along with real world examples of how to use them…

2 Likes
#31

I’ve got a bunch of 24-bit WAV files I need to convert into 16-bit. Here’s a command I ended up with:
find . -name '*.wav' -type f -print0 | xargs -0 -t -r -I {} sox {} -r 44100 -b 16 {}
It got so close to working but since I’m saving the files with the same name they all got corrupted. How could I fix this? It probably makes most sense to move them into a different directory.
Thanks in advance

1 Like
#32

One-liners are amazing, however I never use them. I find it much easier to make “real” code, it’s easier to get working, it’s easier to maintain…

#!/bin/bash
tmp=$(mktemp /tmp/tmp.XXXX.wav)
for i in `find . -name '*.wav' -type f`; do
    sox $i -r44100 -b16 $tmp
    mv $tmp $i
done
4 Likes
#33

Julia Evans (@b0rk on twitter) has some great command line tips in the form of comics on her site: https://wizardzines.com/comics/#bite-size-command-line

3 Likes
#34

people are all over find lately but I find piping ls through grep easier to remember – you can replace the whole find bit with ls | grep -e wav$ if all the files are in the directory you’re working in (ie not a subdirectory). ls lists all the files in the working directory, grep -e filters the input by a regular expression (you might also have egrep available which does the same), wav$ is a regular expression which matches any file or folder ending in wav

#35

I was just trying to match the @john-smith example as close as possible.

As you mention ls is local, find is recursive…

#36

oh yeah, didn’t mean that as a criticism, just another way of doing things

[edit: that said, I should really just get around to internalizing the find flags…]

#37

Check this out:

find | grep wav$

versus

ls | grep wav$

No need for -e! find and ls to me are equally easy to remember (in basic forms), but are both useful in different situations…

1 Like
#38

semi related to find but not much else— i recently discovered fzf, super helpful

#39

Thanks for putting that together — it was largely the fact that I needed to create temporary files that was throwing me off :slight_smile:

#40

The reason for find is its ability to make complex decisions as it traverses a file system tree; Find is not just a “set of flags” but an ordered set of instructions on how to search that tree, including which nodes to enumerate and which branches to cull (this is why the man/info pages are so extensive). Ls only has as much power to traverse as shell globbing affords, and no ability to arrest traversal. Using find where a shell glob would work is unnecessary, but shell globs and ls are in no sense a replacement for find.

1 Like
#41

Actually I’m finding this isn’t working. :confused: First of all it didn’t seem to be able to handle spaces in folder names, then when I removed spaces it just did… nothing. I can’t see anything I’m doing wrong on my end, very confusing

#42

Shell scripts have a tough time with filenames that have spaces, though usually that goes away if you put variables inside of quotes “$like_this”.

#43

For spaces and other special characters, you’ll need to escape them with a \
Such as:

$ find . -name Unreal\ Projects
./Unreal Projects
./Documents/Unreal Projects
1 Like
#44

Again: I was deliberately trying to work with your original one-liner. Yeah spaces in are not so fun.

On topic: I don’t have any spaces in file names, which to me seems like the simplest solution

Off topic: when doing more involved tasks, I quickly switch to python (from bash), I find it much more robust and elegant. For a purpose similar to yours I wrote a python script “a2wav”, which is an elaborate wrapper around sox.

1 Like
#45

Has anyone been playing with Ish? It’s an Alpine emulator for ipadOS/iOS. I almost entirely set up a Pi Hole with it :grinning:

1 Like
#46 
for file in *.wav; do ffmpeg -i $file -ar 44100 -b:a 320k ${file%.*}.mp3; done

save yourself (from all that clicking seriously)

edit: bonus: id3mtag

6 Likes