Split many process and file utils.

README.md

@@ -56,18 +56,44 @@ Generic data formats:
 - [unicode.md](unicode.md)
 - [xml/](xml/)
 
-[virtual-machine.md/](virtual-machine): Vagrant, Docker.
+File and directory related utilities:
+
+- [fdupes.md](fdupes.md)
+- [find.md](find.md)
+- [locate.md](locate.md)
+- [ls.md](ls.md)
+- [tree.md](tree.md)
 
 Programming tools:
 
 - [compile/](compile/): compilation process, dynamic libraries.
 - [ack.sh](ack.sh)
 
+[virtual-machine.md/](virtual-machine/): Vagrant, Docker.
+
+Process control:
+
+- [chroot.sh](chroot.sh)
+- [env.sh](env.sh)
+- [jobs.sh](jobs.sh)
+- [lsof.md](lsof.md)
+- [nice.sh](nice.sh)
+- [nohup.sh](nohup.sh)
+- [ps.sh](ps.sh)
+- [pstree.sh](pstree.sh)
+- [pwd.sh](pwd.sh)
+- [sleep.sh](sleep.sh)
+- [top.sh](top.sh)
+- [wait.sh](wait.sh)
+
+Other tools:
+
+- [eval.sh](eval.sh)
+
 Related subjects in other repositories:
 
 - [networking](https://github.com/cirosantilli/net): networking tools and protocols: HTTP, SSH, curl Apache.
 
-
 #How to search for stuff
 
 If you know what you are searching for, use the following methods to search by keyword.

chroot.sh

@@ -0,0 +1,28 @@
+# Execute single command with new root.
+
+# The root of a process is a Linux concept: every process descriptor has a root field,
+# and system calls issued from that process only look from under the root (known as `/` to that process).
+
+##application
+
+  # You have a partition that contains a linux system,
+  # but for some reason you are unable to run it.
+
+  # You can use that partition with bash by using chroot into it,
+  # and you might then try to fix it from there.
+
+  # Example:
+
+    sudo chroot /media/other_linux/
+
+  # More advanced example, if you want to start from a completelly clean bash environment:
+
+    sudo chroot /media/other_linux /bin/env -i \
+        HOME=/root         \
+        TERM="$TERM"        \
+        PS1='\u:\w\$ '       \
+        PATH=/bin:/usr/bin:/sbin:/usr/sbin \
+        /bin/bash --login
+
+  # This will in addition clear enviroment variables, and read login scripts found on the chroot.
+

env.sh

@@ -0,0 +1,37 @@
+# POSIX 7
+
+# Shows all environment variables and their values:
+
+  env
+
+# Change environment for a single command:
+
+  a=b
+  env a=c echo $a
+  #c
+  echo $a
+  #b
+
+# In bash it is also possible to do (not sure about portability):
+
+  a=b
+  a=c echo $a
+  #c
+  echo $a
+  #b
+
+##-i
+
+  #exec in a clean environment:
+
+    [ "`env -i a=b env`" = "a=b" ] || exit 1
+
+  ##start a subshell in the cleanest env possible
+
+    #don't forget: subshells inherit all exported vars
+
+      env -i bash --noprofile --norc
+      env
+      #some default vars might still be there!
+      #I get: SHLVL, PWD
+      exit

eval.sh

@@ -0,0 +1,19 @@
+# POSIX 7.
+
+# Exec string in current bash
+
+  eval "a=b"
+  [ $a = b ] || exit 1
+
+# Concatenates arguments, space separated:
+
+  [ `eval echo a` = a ] || exit 1
+
+##applications
+
+  # Make varname from var>
+
+    a=b
+    eval "$a=c"
+    [ $b = c ] || exit 1
+

fdupes.md

@@ -0,0 +1,16 @@
+#fdupes
+
+Fine command line tool for eliminating byte by byte duplicates you can either:
+
+-   pick one by one
+
+-   tell fdupes to pick the first one without asking
+    (seem to pick one of the directories first always)
+
+Finds and prints dupes:
+
+    fdupes -r .
+
+Finds dupes, and prompt which to keep for each match
+
+    fdupes -rd .

file.md

@@ -0,0 +1,26 @@
+#file
+
+POSIX 7
+
+Attempts to determine file type and retrieve metadata.
+
+This is in general impossible,
+but program makes good guesses.
+
+    echo a > a
+    file a
+
+Output:
+
+    a: ASCII text
+
+##L
+
+Follow links:
+
+    $ echo a > a
+    $ ln -s a b
+    $ file b
+    b: symbolic link to `a'
+    $ file -L b
+    b: ASCII text

filesystem.md

@@ -782,32 +782,6 @@ List mounted filesystems:
 
     cat /proc/mounts
 
-#fuser
-
-View which processes are using a device:
-
-    fuser -m /dev/sdb1
-
-Useful if you want to unmount a filesystem, and you have to find out who is still using it.
-
-#lsof
-
-List all open files and pipes.
-
-- `COMMAND`: process name.
-- `PID`:     process ID
-- `USER`:    username
-- `FD`:      file descriptor
-- `TYPE`:    node type of the file
-- `DEVICE`:  device number
-- `SIZE`:    file size
-- `NODE`:    node number
-- `NAME`:    full path of the file name.
-
-Usage:
-
-    lsof
-
 #fsck
 
 File System Check.

fuser.md

@@ -0,0 +1,32 @@
+#fuser
+
+View which processes are using a device.
+
+On Ubuntu, comes from the `psmisc` package.
+
+Similar to `lsof`.
+
+    exec 3<> /tmp/foo
+    fuser /tmp/foo
+      #/tmp/foo:            22924
+    exec 3>&-
+    fuser /tmp/foo
+      #
+
+Useful if you want to unmount a filesystem, and you have to find out who is still using it.
+
+#k
+
+Send `SIGKILL` to found process
+
+#t
+
+Search in given domain instead of file paths.
+
+Possible values:
+
+- `tcp`: TCP ports
+
+Good combo with `k` to kill that pesky test server:
+
+    fuser -kn tcp 3000

jobs.sh

@@ -0,0 +1,52 @@
+# Shows:
+
+# - jobspec   : a local job id.
+# - status    : runnning, stopped, done
+# - invocation  : exact program call, including command line args. Ex: `ls ~`
+
+  jobs
+
+# Show pids of background jobs:
+
+  jobs -p
+
+##jobspecs
+
+  # Local job id, found by using <#jobs>
+
+  # Certain commands such as `kill`, `fg` them in addition to pids.
+
+  # They are:
+
+  # - %N	Job number [N]
+  # - %S	Invocation (command line) of job begins with string S
+  #  If several matches, ambiguous, and does nothing.
+  # - ?S	Invocation (command line) of job contains within it string S
+  # - %%	"current" job (last job stopped in foreground or started in background)
+  # - %+	"current" job (last job stopped in foreground or started in background)
+  # - %-	last job
+
+# It is possible to use jobspecs directly with certain bash built-ins that could also take PID.
+# For example, to kill process by jobspec `%1`:
+
+  #kill %1
+
+# Note that `kill` also usually exists as an external executable, and that the external executable
+# cannot kill by jobspec since this information is only known by bash itself.
+
+# `help kill` states that one of the reasons why `kill` is implemented as a bash built-in is to be
+# able to write `kill %1`.
+
+#ls &
+#sleep 100 &
+#sleep 100 &
+#sleep 100 &
+  #runs on background
+  #
+  #[1] 12345678
+  #means local id 1
+  #process number 12345678
+  #
+  #when process ends, it prints ``[n] 1234`` and disappears
+  #
+  #stdout continues to go to cur terminal, even if in bg

kernel/README.md

@@ -875,7 +875,6 @@ and is now just waiting for the system to come and free its resources.
 
 The following transitions are possible:
 
-
     +----------+ +--------+
     |          | |        |
     v          | v        |

kill.sh

@@ -0,0 +1,61 @@
+# POSIX 7
+
+# On Ubuntu 12.04, implemented by the procps package.
+
+# Kill exists as a bash built-in.
+# One of the reasons for this is to allow users to `kill` by jobspec for example as `sleep 1- &; kill %1`,
+# Which an external executable could not do. Killin gby PID is required by POSIX 7.
+
+# Send signals to a process. Signals are an ANSI C concept, with POSIX and Linux extensions.
+
+# Does not necessarily send SIGKILL, nor is SIGKILL the default signal sent!
+# The default signal it sends is SIGTERM.
+
+# It is unfortunatelly named kill because most signals end up killing process,
+# or also because the most used signal is SIGTERM generated by a C-C on the terminal.
+# which has the usual effect of killing a process.
+
+# List all signals available on the system:
+
+  kill -l
+
+# Lists numbers and descriptions.
+
+# Send SIGTERM signal to process:
+
+  ps -A
+  ID=
+  kill $ID
+
+# SIGTERM is the default signal sent by `kill`.
+
+# Select by pid, found on ps for example.
+
+# Select by job-id found on jobs:
+
+  sleep 10 &
+  jobs
+  kill %1
+
+# POSIX specifies this.
+
+# Send stop signal to process:
+
+  kill -s SIGSTOP $ID
+  kill -s sigstop $ID
+  kill -s STOP $ID
+  kill -s stop $ID
+
+# All of the above are specified by POSIX.
+
+# Where `SIGSTOP` is the standard signal name.
+
+# Also possible with the XSI extension:
+
+  kill -SIGSTOP $ID
+  kill -sigstop $ID
+  kill -STOP $ID
+  kill -stop $ID
+
+# But not recommended because it is less uniform parameter passing,
+# and not guaranteed to be on all implementations.

killall.sh

@@ -0,0 +1,17 @@
+# Send signals to all process by name
+
+# On Ubuntu, comes from the psmisc package.
+
+# Application: firefox/skype hanged. `ps -A | grep -i firef',
+# confirm that the name is firefox and that it is the only one with that name, and then:
+
+  killall firefox
+
+# This sengs SIGTERM, which programs may be programmed to handle,
+# so the progrma may still hang ( and in theory be trying to finish nicelly, although in practice this never happens... )
+
+# Kill it without mercy:
+
+  killall -s 2
+
+# which sends SIGINT, which processes cannot handle, so they die.