Is it possible to change the location of .zcompdump and .zhistory files generated by ZSH?
They are polluting my Home Directory.
One possible solution I found was changing the value of $ZDOTDIR to $HOME/.config/zsh. I did the following, but it does not seem to work (temp files are still created in the home directory).
$ cat ~/.zshenv
ZDOTDIR=$HOME/.zsh
. $ZDOTDIR/.zshenv
.zcompdump files are produced to speed up the running of compinit, Which initializes the shell completion in zsh. You could specify an explicit dump file by compinit -d <dumpfile> in your .zshrc to change the location where compdump are stored.
Change the value for HISTFILE to set different location to store you zsh command history.
$ man zshall
/Use of compinit
To speed up the running of compinit, it can be made to produce a dumped
configuration that will be read in on future invocations; this is the
default, but can be turned off by calling compinit with the option -D. The
dumped file is .zcompdump in the same directory as the startup files (i.e.
$ZDOTDIR or $HOME); alternatively, an explicit file name can be given by
`compinit -d dumpfile'. The next invocation of compinit will read the
dumped file instead of performing a full initialization.
Related
Using any of the standard Robot libraries, is it possible to recursively copy the contents of a directory to an existing destination directory?
Basically, I'm looking for the equivalent of the following shell command: cp -r foo/. bar (note the trailing dot)
I tried Copy Directory but this creates a directory foo inside bar (as documented) and it doesn't stop doing that even when supplying the trailing dot. Copy Files chokes when it encounters a directory.
Is there anything I overlooked? Or do I need to just call cp -r myself?
As I only need this to work on Linux, I ended up implementing a custom keyword calling cp -r. If this is ever needed cross-platform, then I'll follow the suggestions to directly implement it in Python.
Copy Directory Contents
[Documentation] Recursively copies the contents of the source directory into the destination.
[Arguments] ${source} ${destination}
Directory Should Exist ${source}
Directory Should Exist ${destination}
${result} = Run Process cp -r ${source}/. ${destination}/
Should Be Equal As Integers ${result.rc} 0
My zsh has some completion features I don't understand and can't find where to change. I have two issues where I suspect they have a similar "fix" for my problem. I initialize the zsh completion system with
autoload -Uz compinit
compinit
to get advanced completion features, but I also get the following problems that I don't have without compinit.
First: I happen to have a directory called mydir in my home directory and unfortunately, there is also a user called mydir. When I want to change into my directory and then use tab completion, i.e.
cd mydir/<TAB>
I get the content directories of ~myusername/mydir/ along with all directories available for ~mydir/. I already tried to put
zstyle ':completion:*' users myusername
in my .zlogin file, but it does only change the completion of the username itself and not subsequent directories. Is there some similar switch to turn off completion of other users' home directories? Alternatively, it would already be good if the current directory completion would appear first in the completion menu.
Second: I wrote a script called setup-file-with-a-long-name.sh that resides in my home directory. When I want to execute it via
source setup-file-with-a-long-name.sh
I start with the first few characters, I press <TAB> and I get a list of lots of executable files that are probably somewhere on my $PATH installed by the system, but I don't care about all those files, I just want my file (which is the only match in the current directory) to be displayed either first in the menu and accessible via <TAB> <TAB> or better yet, be accepted after the first <TAB>. (If I select any of them, they don't work anyway because source needs the absolute path, not the filename. Therefore this is a behavior I don't understand and can't see how this is useful as a default for anybody.)
Possible workarounds:
1. Write ~/ explicitly - this is what I want to avoid, because I have to ssh into a new shell pretty often and want to start navigating without thinking about whether I am in $HOME or not.
2. Don't use compinit - well, I like the context-aware completion in principle, I just want to adapt it to my needs.
The following works in bash,
man source -
source filename [arguments]
Read and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename. If filename does not contain a slash, file
names in PATH are used to find the directory containing filename. The file searched for in PATH need not be executable. When bash is not in posix mode, the current directory is searched if
no file is found in PATH. If the sourcepath option to the shopt builtin command is turned off, the PATH is not searched.
to disable the flag instructions are a little above the description of sourcepath
shopt [-pqsu] [-o] [optname ...]
Toggle the values of variables controlling optional shell behavior. With no options, or with the -p option, a list of all settable options is displayed, with an indication of
whether or not each is set. The -p option causes output to be displayed in a form that may be reused as input. Other options have the following meanings:
-s Enable (set) each optname.
-u Disable (unset) each optname.
-q Suppresses normal output (quiet mode); the return status indicates whether the optname is set or unset. If multiple optname arguments are given with -q, the return
status is zero if all optnames are enabled; non-zero otherwise.
-o Restricts the values of optname to be those defined for the -o option to the set builtin.
...
sourcepath
If set, the source (.) builtin uses the value of PATH to find the directory containing the file supplied as an argument. This option is enabled by default.
so executing the following should remove path from your tab completion...
shopt -u sourcepath
I used this command on my folder in unix:
chmod -R go-rwx *
in order to change permissions for group and others.
Doing this, many files turned green coloured, even simple data files.
Why did this happened?What does it mean?
Is it going to affect my files in a bad way?
They seem to work right now, but I'm concerned about their general functionality.
Thanks!
It is very unlikely that the command you mentioned would cause ls to print your files in green. When ls colors are enabled, executable files are printed in light green by default. Since chmod +R go-rwx only removes permissions, it cannot have caused any files to be marked as executable, and hence won't have made ls print them in green.
Instead, I believe the cause of this is a different command you must have entered, which accidentally marked all those files as executable. This is actually pretty common. Here is the typical scenario: You want to make a directory and all subdirectories readable and possible to enter for all users. So you do chmod -R a+rx top_directory. This works, but as a side effect you have also set the executable flag for all the normal files in all those directories too. This will make ls print them in green if colors are enabled, and it has happened to me several times. You can avoid this by doing chmod -R a+rX top_directory instead, which will only set the executable bit for directories.
To make your files stop being green, you must clear those executable bits. If none of the files in these directories are actually supposed to be executable, this is simple:
$ chmod -R a-x top_directory
$ chmod -R u+X top_directory
This will remove the executable flag for all files and directories, and then add it back for directories only (for the current user). But if some of the files are actually supposed to be executable, you will have to go through them and fix things manually, which can be tedious.
Having some files incorrectly marked as being executable is not a big problem. They will still function normally. It's just a bit messy, and they may show up in command tab completion if the current directory (.) is in your $PATH. So you can safely ignore this issue.
That is an ls functionality:
--color[=WHEN]
colorize the output. WHEN defaults to 'always' or can be 'never' or 'auto'. More info below
Using color to distinguish file types is disabled both by default and with --color=never. With --color=auto, ls emits color codes only when standard output is connected to a terminal. The LS_COLORS environment variable can change the settings. Use the dircolors command to set it.
You can try with ls --color=never and you won't see the colors anymore.
You can see your color configuration with dircolors -p.
This is the line where the executables files configuration resides:
# This is for files with execute permission:
EXEC 01;32
That's just to help you identify file types, so it's not affecting your files in any bad way.
I have a personal scripts folder: ~/google_drive/code/scripts. This folder is on my $path. $path is set in ~/.zshenv and not changed anywhere else (I've disabled OS X path_helper and I don't touch $path in any other zsh startup file). In this scripts folder, there is a subdirectory called alfred_workflows. From the command line, from any location I am able to run scripts in this folder with relative paths. This is expected:
$ alfred_workflows/test.sh
#=> test successful
But in a script, this does not work. It generates an error:
$ zsh -c "alfred_workflows/test.sh"
#=> zsh:1: no such file or directory: alfred_workflows/test.sh
Once again, the scripts directory that contains alfred_workflows is on $path, which is set in ~/.zshenv, and I am able to run executables that reside in the top level of this directory from a script. The issue only seems to be when I try to go through a subdirectory. What might be the problem?
Searching of the $path is only done for names containing a slash if the
path_dirs option is set. Apparently that's set in your interactive shell,
but isn't set in the process that's executing the script.
When setting the export path in Unix, example:
export PATH=$PATH: $EC2_HOME/bin
If I quit terminal and open it back up to continue working, I have to go through all the steps again, setting up the paths each time.
I'm wondering how I can set the path and have it "stick" so my system knows where to find everything the next time I open terminal without having to do it all over again.
Thanks!
Open ~/.bashrc. This file is loaded every time you start up a new shell (if you're using Bash, which most people are). If you're using a different shell, the file may have a different name, like ~/.shrc.
Add the line you need to the bottom of the file:
export PATH=$PATH:$EC2_HOME/bi
Other info rolled up from elsewhere in the thread:
There are multiple places to put this, depending on your shell and your needs. All of these files are in your home directory:
For Bash:
.bashrc (executed when you shart a shell)
OR
.bash_profile (executed when you log in)
For csh and tcsh:
.cshrc
For sh and ksh:
.profile
Add it to your .cshrc file (for csh and tcsh), .profile file (for sh and ksh), or .bash_profile file (for bash)
You need to find your profile file and put that line in there. Suppose you use bash, the profile files are .bashrc and .bash_profile, found in ~. These files will vary depending on which shell you use.
You have to put those commands into one of the "autostart" files of your shell.
For bash this would be .bashrc in your homedirectory (create it if necessary)
add it to your .bashrc or another .bash startup file.
... and for ksh edit .profile.