Tag Info

Hot answers tagged

8

Because there's no command called emacs -nw. There's a command called emacs to which you can pass a -nw option. To store commands, you generally use functions: foo() emacs -nw "$@" foo ... To store several arguments, you generally use arrays: foo=(emacs -nw) $foo ... To store a string containing several words separated by spaces and have it split on ...


4

try: cd /usr/bin; su. Since you didn't give an absolute path to zsh. su is checking the PWD. changing to the directory zsh exists in will work on some systems. an example: % su Password: su: zsh: No such file or directory % cd /usr/local/bin % su Password: # print $OSTYPE freebsd10.0 #


4

Your entry in /etc/passwd is root:x:0:0:root:/root:zsh This is an invalid entry: the shell must be a full path to an executable, the login program does not perform $PATH lookup. You won't be able to log into the root account by normal means. You can use sudo to invoke a command, e.g. sudo vipw, if your account has sudo permissions. This is the only ...


4

You have as much history as you want: cd() { [ "$((${DIRSTACKMAX##*[!0-9]*}0/10))" -gt 0 ] && set -- "$@" "$DIRSTACK" && DIRSTACK='pwd -P >&3; command cd' || { command cd "$@"; return; } _q() while case "$1" in (*\'*) : ;; (*) ! DIRSTACK="$DIRSTACK '$2$1'" ;;esac ...


3

Not the issue of ls. It's how symlinks work. The .. gets you into the parent of the current directory, the directory doesn't know you got to it through a symlink. The shell has to intervene to prevent this behaviour. For the shell builtin cd, there is special handling that doesn't just call chdir but memorizes the full directory path and tries to figure out ...


3

By default, tmux spawns a login shell for all new windows. This would then source your ~/.zprofile or wherever your start your ssh-agent. As man tmux makes clear, you can avoid this behaviour by explicitly setting a default command in your ~/.tmux.conf: default-command shell-command Set the command used for new windows (if not ...


2

I don't have an explanation for why they did it this way, but ${:-foo...} does have an application: it counts as a parameter substitution in places that syntactically require one, but always just expands to a literal you give. You can write things like this to use expansion flags or other expansion specifiers on a literal string in-place: $ echo ...


2

When combined with other features of parameter expansions, it allows you to do a few clever tricks. A couple examples: # strftime date via prompt sequences tar -cpf ${(%):-%D{%Y%m%d}}-/etc.tar /etc # brace expansion, but separated by commas via PE flags and nesting PEs. print ${(j:,:)${:-{1..10}}}


2

By default, zsh expands alias before doing completion. It's possible that your configuration disables this; you can reenable it explicitly by unsetting the complete_aliases option. unsetopt complete_aliases For an external command like proxychains4, you can declare that its arguments are themselves a command and its arguments by making its completion ...


2

You have two choices: you can pass a program to execute with some arguments, or you can pass a shell script. Both concepts can be called “a command”. A program with some arguments takes the form of a list of strings, the first of which is the path to an executable file (or a name not containing any slash, to be looked up in the list of directories indicated ...


2

zsh -x 2>zsh.trace exit grep 'alias.*subl' zsh.trace The -x option causes zsh to print out every command that it executes on stderr. Any command that was executed from reading a file has a prefix with the file name and line. So look for the alias definition in the trace file and you'll know where it was defined.


2

Others already covered some interesting solutions. Some time ago I created my own solution to a related problem that could be quickly modified to do "straight history". I basically wanted to "label" a few commonly used directories, and wanted all open shells to see them, and for them to persist between reboots. #dir_labels #functions to load and retrieve ...


2

Check your current shell with grep '^root:' /etc/passwd you should see at the end of the line full path to shell used by root user, like /bin/zsh. Then check if the path is not misspelled, file exists and has proper permissions set (read and execute). If path was not correct then check where your zsh executable is placed with type zsh After that su to ...


2

It shouldn't, since you're not running zsh interactively. Quoting man zsh (section STARTUP/SHUTDOWN FILES): [I]f the shell is interactive, commands are read from /etc/zshrc and then $ZDOTDIR/.zshrc. You could try using -i: -i Force shell to be interactive. It is still possible to specify a script to execute.


1

For future readers it should be mentioned that the "standard" way of doing such thing is to evaluate the arguments stored in variable: eval "$foo" One can also evaluate expression with command substitution: $(expr "$foo") echoed variable (or otherwise printed) works as well: $(echo "$foo") These methods works fine at least in zsh and bash.



Only top voted, non community-wiki answers of a minimum length are eligible