adds umask and input redirect
This commit is contained in:
waldek
parent
33e1323a4c
commit
10605055d6
|
|
@ -571,7 +571,61 @@ steve@debian:/home/waldek$
|
|||
|
||||
## `umask`
|
||||
|
||||
TODO
|
||||
When you create a **new** file of directory, there are created with default permissions according to the `umask`.
|
||||
|
||||
```
|
||||
waldek@helloworld:~$ whatis umask
|
||||
umask (2) - set file mode creation mask
|
||||
waldek@helloworld:~$ umask
|
||||
0022
|
||||
waldek@helloworld:~$ touch new_file && ls -l new_file
|
||||
-rw-r--r-- 1 waldek waldek 0 Jun 15 15:02 new_file
|
||||
waldek@helloworld:~$ mkdir new_folder && ls -la new_folder
|
||||
total 8
|
||||
drwxr-xr-x 2 waldek waldek 4096 Jun 15 15:03 .
|
||||
drwxr-xr-x 59 waldek waldek 4096 Jun 15 15:03 ..
|
||||
waldek@helloworld:~$
|
||||
```
|
||||
|
||||
The `new_file` has a octal permission of `644` and the `new_folder` `755`.
|
||||
I can change my `umask` as follows.
|
||||
|
||||
```
|
||||
waldek@helloworld:~$ rm -r new_f*
|
||||
waldek@helloworld:~$ umask 000
|
||||
waldek@helloworld:~$ touch new_file && ls -l new_file
|
||||
-rw-rw-rw- 1 waldek waldek 0 Jun 15 15:08 new_file
|
||||
waldek@helloworld:~$ mkdir new_folder && ls -la new_folder
|
||||
total 8
|
||||
drwxrwxrwx 2 waldek waldek 4096 Jun 15 15:08 .
|
||||
drwxr-xr-x 59 waldek waldek 4096 Jun 15 15:08 ..
|
||||
waldek@helloworld:~$
|
||||
```
|
||||
|
||||
The permissions changed!
|
||||
The `new_file` now has a octal permission of `666` and the `new_folder` `777`.
|
||||
Do you see a pattern here?
|
||||
The `umask` value is subtracted from the [POSIX](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_01_01_04) defined base permissions which are `666` for a file and `777` for a directory.
|
||||
One more example to drive it home.
|
||||
|
||||
```
|
||||
waldek@helloworld:~$ rm new_f*
|
||||
rm: cannot remove 'new_folder': Is a directory
|
||||
waldek@helloworld:~$ rm -r new_f*
|
||||
waldek@helloworld:~$ umask 777
|
||||
waldek@helloworld:~$ touch new_file && ls -l new_file
|
||||
---------- 1 waldek waldek 0 Jun 15 15:11 new_file
|
||||
waldek@helloworld:~$ mkdir new_folder && ls -la new_folder
|
||||
ls: cannot open directory 'new_folder': Permission denied
|
||||
waldek@helloworld:~$
|
||||
```
|
||||
|
||||
Can you explain me why we get a `Permission denied` message?
|
||||
Some of you might have noticed the `umask` returns **4** digits.
|
||||
This is because there is an additional permission bit we have not covered yet.
|
||||
If you want to dig into it I suggest [this](https://wiki.debian.org/Permissions#Section_2:_UNIX_permissions_explained) page on the Debian wiki where I got the following quote from.
|
||||
|
||||
> The first of the 4 octal digits which represent permissions contains the setuid and setgid bits. These can be used to override some of the defaults described above but it is not worth getting into details other than to note that the user private groups project collaboration idiom (see below) depends on the behavior of the setgid bit.
|
||||
|
||||
## Essential programs
|
||||
|
||||
|
|
|
|||
|
|
@ -984,8 +984,7 @@ waldek@hellodebian:~/Documents$
|
|||
|
||||
## Links
|
||||
|
||||
TODO
|
||||
|
||||
TODO - symlinks
|
||||
|
||||
# Editors
|
||||
|
||||
|
|
@ -1188,7 +1187,7 @@ waldek@debian:~$
|
|||
```
|
||||
|
||||
You'll probably be a bit confused by the `|` part of the commands above.
|
||||
Don't worry, give it a few hours paragraphs and it will become fully transparent!
|
||||
Don't worry, give it a few hours and it will hopefully become fully transparent!
|
||||
|
||||
Next, there is a very high probability that the commands above don't immediately work for you.
|
||||
This is because `locate` functions with a database which needs to be updated from time to time.
|
||||
|
|
@ -1333,7 +1332,7 @@ Adding the `--color` argument to `grep` will make the matched patterns jump out
|
|||
## Wild cards and regular expressions
|
||||
|
||||
Both are quite related and for simplicities sake you can view regular expressions as wild cards on steroids.
|
||||
A more detailed explaination can be found [here](https://unix.stackexchange.com/questions/57957/how-do-regular-expressions-differ-from-wildcards-used-to-filter-files).
|
||||
A more detailed explanation can be found [here](https://unix.stackexchange.com/questions/57957/how-do-regular-expressions-differ-from-wildcards-used-to-filter-files).
|
||||
|
||||
### Wild cards
|
||||
|
||||
|
|
@ -1382,7 +1381,7 @@ waldek@helloworld:~$
|
|||
I hid a lot of words in [this](../assets/find_words_in_here.txt) file.
|
||||
How many can you find?
|
||||
What do they all have in common?
|
||||
Can you count the occurences?
|
||||
Can you count the occurrences?
|
||||
|
||||
* [exercise from Linux long](https://gitea.86thumbs.net/waldek/linux_course_doc/src/branch/master/modules/qualifying/learning_regex.md)
|
||||
|
||||
|
|
@ -1392,7 +1391,34 @@ TODO
|
|||
|
||||
# Pipes and redirects
|
||||
|
||||
TODO basic overview
|
||||
I mentioned before that `bash` only knows *characters*.
|
||||
It was kind of a lie.
|
||||
`bash` only knows **bytes** at it's input and output.
|
||||
If these bytes can be interpreted as *characters* you'll see readable output on your terminal, if not you'll see some gibberish.
|
||||
An example.
|
||||
|
||||
```
|
||||
waldek@helloworld:~$ echo "$(dd if=/dev/urandom bs=64 count=1 status=none)"
|
||||
<EFBFBD>B<EFBFBD><EFBFBD>-<2D>j<EFBFBD><6A><EFBFBD><EFBFBD><EFBFBD><EFBFBD>s<EFBFBD>Ɠ8<C693><38>J<EFBFBD>!
|
||||
<20>ד<EFBFBD>7d<37>/<2F>X<EFBFBD><58><EFBFBD><EFBFBD>!@{<7B>{R<><52><EFBFBD><EFBFBD><EFBFBD><EFBFBD>J):<3A>sB<73><42>+c<>1<EFBFBD>
|
||||
waldek@helloworld:~$
|
||||
```
|
||||
|
||||
Recognise this *gibberish*?
|
||||
It's very similar to the output we got when reading a binary file no?
|
||||
The command above generates 64 random bytes and print them to the screen.
|
||||
We can do the same for a string and can use `pv` to get some statistics.
|
||||
|
||||
```
|
||||
waldek@helloworld:~$ whatis pv
|
||||
pv (1) - monitor the progress of data through a pipe
|
||||
waldek@helloworld:~$ echo "hello world" | pv
|
||||
hello world
|
||||
12.0 B 0:00:00 [ 116KiB/s ] [ <=> ]
|
||||
waldek@helloworld:~$
|
||||
```
|
||||
|
||||
Don't worry about the `|` symbol, that's up next!
|
||||
|
||||
## Redirecting
|
||||
|
||||
|
|
@ -1640,7 +1666,41 @@ waldek@debian:~$ grep -R waldek /etc/ &> files_with_my_name
|
|||
waldek@debian:~$
|
||||
```
|
||||
|
||||
TODO - input redirection
|
||||
### Input redirection
|
||||
|
||||
This is a bit more exotic but widely used in scripting.
|
||||
I personally don't use it that often on the command line.
|
||||
But we can demonstrate it's behaviour with a simple TCP server.
|
||||
|
||||
In a **first** terminal I run the following command.
|
||||
If you try this out you'll see it *hang* after hitting enter, this is normal, the server is now listening for incoming connections
|
||||
|
||||
```
|
||||
waldek@helloworld:~$ cat message
|
||||
hello world!
|
||||
I'm a text file...
|
||||
|
||||
waldek@helloworld:~$ cat < message
|
||||
hello world!
|
||||
I'm a text file...
|
||||
|
||||
waldek@helloworld:~$ nc -l -p 9999 < message && echo "done serving the file"
|
||||
done serving the file
|
||||
waldek@helloworld:~$
|
||||
```
|
||||
|
||||
In a **second** terminal I now connect to this server.
|
||||
I receive the content of the text file here and when I hit `ctrl-c` I break the connection.
|
||||
The first terminal will now continue and say `done serving the file`.
|
||||
|
||||
```
|
||||
waldek@helloworld:~$ nc localhost 9999
|
||||
hello world!
|
||||
I'm a text file...
|
||||
|
||||
^C
|
||||
waldek@helloworld:~$
|
||||
```
|
||||
|
||||
## Piping
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue