This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I have been on this issue for a couple days now. I use zsh and need to set a directory path so that the command i use will be recognized. Following these steps so far:
cd ~
ls -al
ls -al shows me these files:
.oh-my-zsh
.profile
.putty
.rediscli_history
.ringo-history
.ssh
.subversion
.viminfo
.zcompdump
.zsh-update
.zsh_history
.zshrc
I assume i need to add the path to .zshrc, so:
open -e .zshrc
At the end of the file, i added the path of the command i will be using to set my project (with ringojs):
export PATH=Users/repos/ringojs/bin/:$PATH
Close the file, restart the terminal application, restart the computer, however the command (ringo-admin) located under the path above (/Users/repos/ringojs/bin) is not found:
ringo-admin create --google-appengine MyAppName
zsh: command not found: ringo-admin
Please help me with that, if it will of some help, here is my .zshrc file content:
# Path to your oh-my-zsh configuration.
ZSH=$HOME/.oh-my-zsh
# Set name of the theme to load.
# Look in ~/.oh-my-zsh/themes/
# Optionally, if you set this to "random", it'll load a random theme each
# time that oh-my-zsh is loaded.
ZSH_THEME="robbyrussell"
# Example aliases
# alias zshconfig="mate ~/.zshrc"
# alias ohmyzsh="mate ~/.oh-my-zsh"
# Set to this to use case-sensitive completion
# CASE_SENSITIVE="true"
# Comment this out to disable bi-weekly auto-update checks
# DISABLE_AUTO_UPDATE="true"
# Uncomment to change how many often would you like to wait before auto-updates occur? (in days)
# export UPDATE_ZSH_DAYS=13
# Uncomment following line if you want to disable colors in ls
# DISABLE_LS_COLORS="true"
# Uncomment following line if you want to disable autosetting terminal title.
# DISABLE_AUTO_TITLE="true"
# Uncomment following line if you want red dots to be displayed while waiting for completion
# COMPLETION_WAITING_DOTS="true"
# Which plugins would you like to load? (plugins can be found in ~/.oh-my-zsh/plugins/*)
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
plugins=(git)
source $ZSH/oh-my-zsh.sh
# Customize to your needs...
export PATH=Users/repos/ringojs/bin/ringo-admin:$PATH
Please guide me step by step, as i am new to zsh. Thanx.
UPDATE:
echo $PATH display me the recently added directory:
/Users/repos/ringojs/bin/ringo-admin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/git/bin
I don't understand why the command is always not found.
You are missing a leading slash. Try:
export PATH=/Users/repos/ringojs/bin/:$PATH
Related
When trying to open a file with text editor VIM, I am unable to open the file unless VIM (shortcut) is in my current working directory. As an example, I am able to write start firefox to open a firefox window. However, start vim C:\filepath\filename.txt does not work unless a vim shortcut is in my current directory. How do I get around this?
Also, is there a way to have a program execute a file in the current working directory without having to reference the entire file path? For example instead of Start-Process vim C:\Users\User\Desktop\File\file.txt is there an available path shortcut like Start-Process vim ~\file.txt with ~ representing the current working directory?
The OS need to determine the full path of the exe, no matter what.
There's 2 ways that it will happen.
You're calling the executable from it's working directory
The executable location is in the Windows environment variable.
You can view the PATH variable content through this simple statement
$env:Path -split ';' | sort
You sill see that the Firefox path is listed there, but not the one from VIM.
That's why the former can be started by it's executable name and the latter require the full path.
You need to add VIM directory to your PATH variable if you want to be able to call it just by typing vim
Otherwise, if you have restricted access or don't want to edit that variable, you can also set a $vim variable, then invoke it whenever you want to call the executable.
Regarding the second part of your question
Powershell use the dot as a reference to the current directory .\file.txt.
You can also just specify the filename without anything else file.txt.
Both backslash \ & slash / work for filepath so .\file.txt and ./file.txt are both valid ways to reference the file.
Use ..\ to reference the parent directory (e.g. ..\file.txt)
$Vim = "c:\Path\To\Vim.exe"
& $vim "file.txt"
& $vim ".\file.txt"
#Forward slash also work for paths
& $vim "./file.txt"
I am a bit out of my wits researching this... and I just have to ask.
I have oh-my-zsh on my Mavericks machine and have everything updated. I also have Xcode and Brew. All updated. According to this page: https://github.com/robbyrussell/oh-my-zsh/wiki/Cheatsheet am I not supposed to just type, say: "g" [tab] and get "git"? or type "md" [tab] and get "mkdir -p"? Right now I just get a list of options I can tab through (or arrow through)... I thought it would autocomplete. What am I missing?
I have a feeling it might be related to my $PATH but that is where I also get confused... where should it point to?
I greatly appreciate and enlightenment.
# Path to your oh-my-zsh configuration.
#ZSH=$HOME/.oh-my-zsh
export ZSH=$HOME/.oh-my-zsh
# Set name of the theme to load.
# Look in ~/.oh-my-zsh/themes/
# Optionally, if you set this to "random", it'll load a random theme each
# time that oh-my-zsh is loaded.
#ZSH_THEME="af-magic"
ZSH_THEME="agnoster"
# Set to this to use case-sensitive completion
# CASE_SENSITIVE="true"
# Comment this out to disable weekly auto-update checks
# DISABLE_AUTO_UPDATE="true"
# Uncomment following line if you want to disable colors in ls
# DISABLE_LS_COLORS="true"
# Uncomment following line if you want to disable autosetting terminal title.
# DISABLE_AUTO_TITLE="true"
# Uncomment following line if you want red dots to be displayed while waiting for completion
COMPLETION_WAITING_DOTS="true"
# Which plugins would you like to load? (plugins can be found in ~/.oh-my-zsh/plugins/*)
# Example format: plugins=(rails git textmate ruby lighthouse)
plugins=(git textmate sublime zsh-syntax-highlighting)
source $ZSH/oh-my-zsh.sh
#export PATH=/usr/local/bin:/usr/local/sbin:/usr/local/git/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/X11/$
#export PATH=$HOME/bin:/usr/local/bin:$PATH
export PATH=/usr/local/bin:$PATH
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
zstyle ':completion:*' list-prompt ''
zstyle ':completion:*' select-prompt ''
autoload -Uz compinit
compinit
Aliases are essentially just short names for commands. Before executing a command zsh internally replaces aliases by their values. But by default aliases are not expanded when using completion (Tab), they are handled just like any other command.
For example:
alias ll='ls -l'
alias la='ls -al'
If you now type lTab, zsh will present you every command starting with an l, including the aliases ll and la. If you type llTab it will probably just add an space after ll (assuming there are no other commands starting with ll).
When you run ll somedir it does the exact same thing as ls -l somedir. You can even add other options of ls: ll -t somedir runs ls -l -t somedir.
That being said, if you want to expand aliases when typing Tab, zsh can do so.
There are two ways:
You can call the _expand_alias widget. In emacs mode (bindkey -e) this is bound to ^Xa (press Control+X then A).
You can add _expand_alias to the completer style. It seems that oh-my-zsh does not change this style from its default value, so adding
zstyle ':completion:*' completer _expand_alias _complete _ignored
to your ~/.zshrc should work.
(To be save you can print the current setting with zstyle -L ':completion:*' completer, _expand_alias has to come before _complete)
If you now type llTab, zsh will replace it with ls -l immediatelly.
Note: in both cases the cursor has to be in or just after the alias for the replacement to happen. This also means you have to type the whole alias or backspace if automatically completed (_completer adds a space after successful completion)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
im trying to install openvpn on my centos 6 box
im using epel repository to install the vpn
all went fine on the installation but somehow when coming to generate certificate part
lots of command not found raised when im typing "source ./vars" command
here is returned from the terminal
[root#... easy-rsa]# source ./vars
: command not found
: command not found
: command not found
: command not found
: command not found
: command not found
: command not found
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys
: command not found
: command not found
: command not found
: command not found
: command not found
here is my vars file setting
# easy-rsa parameter settings
# NOTE: If you installed from an RPM,
# don't edit this file in place in
# /usr/share/openvpn/easy-rsa --
# instead, you should copy the whole
# easy-rsa directory to another location
# (such as /etc/openvpn) so that your
# edits will not be wiped out by a future
# OpenVPN package upgrade.
# This variable should point to
# the top level of the easy-rsa
# tree.
export EASY_RSA="`pwd`"
#
# This variable should point to
# the requested executables
#
export OPENSSL="openssl"
export PKCS11TOOL="pkcs11-tool"
export GREP="grep"
# This variable should point to
# the openssl.cnf file included
# with easy-rsa.
export KEY_CONFIG=/etc/openvpn/easy-rsa/openssl.cnf
# Edit this variable to point to
# your soon-to-be-created key
# directory.
#
# WARNING: clean-all will do
# a rm -rf on this directory
# so make sure you define
# it correctly!
export KEY_DIR="$EASY_RSA/keys"
# Issue rm -rf warning
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
# PKCS11 fixes
export PKCS11_MODULE_PATH="dummy"
export PKCS11_PIN="dummy"
# Increase this to 2048 if you
# are paranoid. This will slow
# down TLS negotiation performance
# as well as the one-time DH parms
# generation process.
export KEY_SIZE=1024
# In how many days should the root CA key expire?
export CA_EXPIRE=3650
# In how many days should certificates expire?
export KEY_EXPIRE=3650
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="US"
export KEY_PROVINCE="CA"
export KEY_CITY="SanFrancisco"
export KEY_ORG="Fort-Funston"
export KEY_EMAIL="me#myhost.mydomain"
export KEY_EMAIL=mail#host.domain
export KEY_CN=changeme
export KEY_NAME=changeme
export KEY_OU=changeme
export PKCS11_MODULE_PATH=changeme
export PKCS11_PIN=1234
any help will be appreciated
thanks
If you notice there are 7 command not found statements before the echo. There are also 7 "empty" lines before the echo. It appears that the key dir variable is properly expanding in the echo statement. After the echo statement there are 5 "empty" lines and 5 more command not found errors. This makes me think that the command not found statements are a result of the "empty" lines.
Obviously if the line is empty it shouldn't cause that sort of an error. How did the "vars" file get there? Did you copy/paste it and invisible characters got copied in the process? Or perhaps it was edited on a device that used a different type of carriage returns?
You should use an editor such as vim on it which will help you see normally hidden characters. You could also try to use a program like tofrodos to convert the carriage returns. When you source a file you are actually executing a script and any variables exported become part of our shell that sourced it in. Normally scripts would conform to unix line endings.
I wrote a little CDN server that rebuilds its registry pool when new pool-content-packages are installed into that registry pool.
Instead of having each pool-content-package call the init.d of the cdn-server, I'd like to use triggers. That way it would restart the server only once at the end of an installation run, after all packages were installed.
What have I to do to use triggers in my packages with debhelper support?
What you are looking for is dpkg-triggers.
One solution with use of debhelper to build the debian packages is this:
Step 1)
Create file debian/<serverPackageName>.triggers (replace <serverPackageName> with name of your server package).
Step 1a)
Define a trigger that watch the directory of your pool. The content of file would be:
interest /path/to/my/pool
Step 1b)
But you can also define a named trigger, which have to be fired explicit (see step 3).
content of file:
interest cdn-pool-changed
The name of the trigger cdn-pool-changed is free. You can take what ever you want.
Step 2)
Add handler for trigger to file debian/<serverPackageName>.postinst (replace <serverPackageName> with name of your server package).
Example:
#!/bin/sh
set -e
case "$1" in
configure)
;;
triggered)
#here is the handler
/etc/init.d/<serverPackageName> restart
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
#DEBHELPER#
exit 0
Replace <serverPackageName> with name of your server package.
Step 3) (only for named triggers, step 1b) )
Add in every content package the file debian/<contentPackageName>.triggers (replace <contentPackageName> with names of your content packages).
content of file:
activate cdn-pool-changed
Use same name for trigger you defined in step 1.
More detailed Information
The best description for dpkg-triggers I could found is "How to use dpkg triggers". The corresponding git repository with examples you can get here:
git clone git://anonscm.debian.org/users/seanius/dpkg-triggers-example.git
I had a need and read and re-read the docs many times. I think that the process is not clearly explain or rather what goes where is not clearly explained. Here I hope to clarify the use of Debian package triggers.
Service with Configuration Directory
A service reading its settings in a specific directory can mark that directory as being of interest.
Say I create a new service which reads settings from /usr/share/my-service/config/...
That service gets two additions:
In its debian directory I add my-service.triggers
And here are the contents:
# my-service.triggers
interest /usr/share/my-service/config
This means if any other package installs or removes a file from that directory, the trigger enters its "needs to be run" state.
In its debian directory I also add my-service.postinst
And I have a script as follow to check whether the trigger happened and run a process as required:
# my-service.postinst
if [ "$1" = "triggered" ]
then
if [ "$2" = "/usr/share/my-service/config" ]
then
# this may or may not be what you need to do, but this is often
# how you handle a change in your service config files
#
systemctl restart my-service
fi
exit 0
fi
That's it.
Now packages adding extensions to your service can add their own configuration file(s) under /usr/share/my-service/config (or a directory under /etc/my-service/my-service.d/... or /var/lib/my-service/..., although that last one should be reserved for dynamic files, not files installed from a package) and dpkg automatically calls your postinst script with:
postinst triggered /usr/share/my-service/config
# where /usr/share/my-service/config is your <interest-path>
This call happens only once and after all the packages were installed, hence the advantage of having a trigger in the first place. This way each package does not need to know that it has to restart my-service and it does not happen more than once, which could cause all sorts of side effects (i.e. the service tries to listen on a TCP port and get error: address already in use).
IMPORTANT: keep in mind that the postinst should include a line with #DEBHELPER#.
So you do not have to do anything special in other packages. Only make sure to install the configuration files in the correct directory and dpkg picks up from there (i.e. in my example under /usr/share/my-service/config).
I have an extension to BIND9 called ipmgr which makes use of .ini files saved in a specific folder. It uses the files to generate DNS zones (way less errors that way! and it includes support for getting letsencrypt certificates and settings for dmarc/dkim). This package uses this case: a simple directory where configuration files get installed. Other packages do not need to do anything other than install files in the right place (/usr/share/ipmgr/zones, for this package).
Service without a Configuration Folder
In some (rare?) cases, you may need to trigger something in a service which is not driven by the installation of a new configuration file.
In this case, you can use an arbitrary name (it should include your package name to make sure it is unique since this name is global to the entire Debian/Ubuntu system).
To make this one work, you need three files, one of which is a trigger in the other packages.
State the Interest
As above, we have an interest. In this case, the interest is stated as a name on its own. The dpkg system distinguish between a name and a path because a name cannot include a slash (/) character. Names are limited to ASCII except control characters and spaces. I would suggest you stick to a-z, 0-9 and dashes (-).
# my-service.triggers
interest my-service-settings
This is useful if you cannot simply track a folder. For example, the settings could come from a network connection that a package offers once installed.
Listen for the Triggers
Again, as above, you need a postinst script in your Service Package. This captures the trigger and allows you to run a command. The script is the same, only you test for the name instead of the folder (note that you can have any number of triggers, so you could also have both: a folder as above and a special name as here).
# my-service.postinst
if [ "$1" = "triggered" ]
then
if [ "$2" = "my-service-settings" ]
then
# this may or may not what you need to do, but this is often
# how you handle a change in your service config files
#
systemctl restart my-service
fi
exit 0
fi
The Trigger
As mentioned above, we need a third file. An arbitrary name is not going to be triggered automatically by dpkg. It wouldn't know whether your other package needs to trigger something just like that (although it is fairly automated as it is already).
So in other packages, you create a trigger file which looks like this:
# other-package.triggers
activate my-service-settings
Now we recognize the name, it is the same as the interest stated above.
In other words, if the trigger needs to run for something other than just the installation of files in a given location, use a special name and add this triggers file with the activate keyword.
Other Features
I have not tested the other features of the dpkg-trigger(1) tool. There are other keywords support in the triggers files:
interest
interest-await
interest-noawait
activate
activate-await
activate-noawait
The deb-triggers manual page has additional information about those. I am not too sure what the await/noawait implies other than the trigger may happen at any time when nowait is used.
Automatic Trigger Added
The build system on Ubuntu (probably Debian too) automatically adds a triggers file with the following when your package includes a library:
$ cat triggers
# Triggers added by dh_makeshlibs/11.1.6ubuntu2
activate-noawait ldconfig
I suggest you exercise caution if your package includes libraries. If you have your own triggers file, I do not know whether this addition will still happen automatically.
This also shows us a special case where it wants to use the noawait. If I understand correctly, it has to run the ldconfig trigger ASAP so your commands will work as expected after the unpack. Otherwise ldd will not know anything about your newly installed library.
I looked at logrotate.conf examples and everything in my /etc/logrotate.d directory. Nowhere was I able to find documentation on variables in these files.
I am trying to create a config file for rotating the logs of an application we are writing. I want to set the directory where logs are stored once, and then use it as a variable, like so:
my_app_log_dir=/where/it/is/deployed/logs
${my_app_log_dir}/*.log ${my_app_log_dir}/some_sub_dir/*.log {
missingok
# and so on
# ...
}
Is that possible?
You can achieve what you are looking for by implementing this kludge:
my-logrotate.conf ( NOTE: double quotes " are mandatory, also note that file names don't have to appear on the same line )
"*.log"
"some_sub_dir/*.log"
{
missingok
# and so on
# ...
}
Then the actual logrotate script - my-logrotate.sh
#!/bin/sh
set -eu
cd "${my_app_log_dir}"
exec logrotate /path/to/my-logrotate.conf
Now you can add logrotate.sh to your crontab.
You can use a bash "here document" to create a suitable config file on the fly, either at installation time or before running logrotate.
A bash script might look like this:
cat >rt.conf <<.
"${my_app_log_dir}/*.log" {
rotate 5
size 15k
missingok
}
.
logrotate rt.conf
Directly in the config file no (as far as my knowledge in logrotate goes).
Other solution:
Use the include option to include parts of the configuration file from a directory. This can help you if you have a package for your application, the package can leave a file in that directory containing only the entries for your app.
With logrotate 3.8.7,a test reveals that you can set and use variables in the pre-rotate and post-rotate script sections.
I tried this for a particular service log file.
postrotate
pid_file="/run/some_service/some_serviced.pid"
test -e "${pid_file}" && kill -s HUP $(cat "${pid_file}") || true
touch "${pid_file}.WAS_USED"
endscript
After running logrotate in force mode to ensure the log file was rotated and the post-rotate script executed, on looking in /run/some_service, there was an additional file "some_serviced.pid.WAS_USED", thus proving that the use of the variable worked.