Just learnt about whiteout files from this, thanks! Trying to understand if you purposely included a filename into a layer with the same whiteout prefix “.wh.”, if it would mess with the process that is meant to obfuscate that prefix from subsequent layers.
$_ is the last argument. Here's a better example to illustrate
> echo 'Hello' 'world' 'my' 'name' 'is' 'godelski'
Hello world my name is godelski
> echo $_
godelski
> !:0 !:1 !:2 "I'm" "$_"
Hello world I'm godelski
The reference manual is here[0] and here's a more helpful list[1]
One of my favorites is
> git diff some/file/ugh/hierarchy.cpp
> git add $_
## Alternatively, but this is more cumbersome (but more flexible)
!!:s^diff^add
So what is happening with wget is
> wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz && tar -xvf $_
## Becomes
> wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz
> tar -xvf https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz
Which you are correct, doesn't work.
It should actually be something like this
> wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz -O alpine.tar.gz && tar xzf $_
This would work as the last parameter is correct. I also added `z` to the tar and removed `-` because it isn't needed. Note that `v` often makes untaring files MUCH slower
If you want to add in another bash trick called Parameter Expansion[0] you can parse out the filename automatically with the special variable $_. Something like:
> wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz && tar xzf ${_##*/}
I want to make a small note, in that `$_` is a special Bashism (though it is supported widely), but Parameter Expansion is POSIX-standard and will work on all POSIX-compliant shells, not just Bash.
I wanted to offer that (if you are "C handy") writing your own shell is a super informative exercise. We had to write our own shell in my operating system class at GT and I actually got it working well enough that I could "exec ./myshell" and use it for some day to day stuff. I felt empowered
iTerm and Terminal are pieces of software emulate a physical terminal environment. They take the output of programs/shells output characters and control codes to render text, clear the screen, etc.
The terminal emulator receives keyboard input via your operating system, and passes it to the shell program via stdin.
The shell is responsible for prompting you and handling whatever you type.
For example the “$ “ waits for next character from the terminal emulator until you hit newline.
The shell is responsible for parsing your input, executing any child programs “ls” for example, outputting their content to stdout, and prompting you again.
I am surprised that this is working, as I always thought that variables get initialized after the full command is parsed. So, I would assume that $_ would be related to the previous command (defined by a new line) and not this one, because there's no newline character here, but only an ampersand.
&& means there's a sequence. So the second statement will only execute conditioned on the first sequence. So...
> thisFunctionFails && echo "Hello world" && echo "I SAID $_"
> thisFunctionSucceeds && echo "Hello world" && echo "I SAID $_"
Hello World
I SAID Hello World
The left function has to get evaluated before the next function. So it is still related to the previous command.
FROM scratch
COPY ./hello /root/
ENTRYPOINT ["./hello"]
> Here, our image contains 2 layers. The first layer comes from the base image, the alpine official docker image i.e. the root filesystem with all the standard shell tools that come along with an alpine distribution.
But I thought "FROM scratch" was an empty container, while "FROM alpine" is a container with alpine libs/executables.
otherwise using "FROM scratch" to populate for example an ubuntu image would pollute the container.
You're right, that doesn't work the way it is shown. Thankfully, a reader(I'm not sure if it's you) pointed this out with a solution[1] that I plan to add to the post shortly. Again, thanks for pointing this out!
