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 11 years ago.
Improve this question
Im using KUbuntu 10.04 (Lucid Lynx). I have installed zsh and screen. I have set zsh as the default shell, by setting Command to zsh in Settings->Edit Current Profile of the terminal.
But,when i launch screen,the bash shell is loaded. If i run the command zsh, then zsh starts but the following message is displayed:
"/home/joel/.zshrc:36: Can't add module parameter `mapfile': parameter already exists"
Also,zsh is invoked for only the current screen instance and i have to invoke it manually again for other instances.
So,is there any way to make screen load zsh by default and invoke it automatically for every instance ?
Thank You
If you want to make it the default shell for screen sessions only, you can simply add this line to your ~/.screenrc file.
shell "/usr/bin/zsh"
First locate where is zsh like that:
$ whereis zsh
Second change shell for current user:
$ chsh -s /path/to/zsh joel
And zsh will be default shell for user joel after relogin.
I had a similar problem to you, except in my case I changed the shell vim uses, by specifying set shell=zsh\ --login in .vimrc. Every time I dropped into a shell via :sh zsh would whine with the same error:
Can't add module parameter `mapfile': parameter already exists
I asked on #vim and #zsh on freenode. Turns out if you run zsh again within a zsh session, you'll see the same error, and the suggested fix is to simply append &>/dev/null to your .zshrc file like so:
zmodload -ap zsh/mapfile mapfile &>/dev/null
The zsh mapfile module creates a pseudo-variable which maps filenames to their contents, and is only needed if you have scripts that actually use $mapfile.
It appears to be optional, but it was pointed out that the autoload parameter is there so it only gets loaded when required, so there should be no harm in keeping the line and piping complaints to /dev/null
Related
I'm writing a shell history application, and I'm experiencing issues with deleting a command from zsh history. When I was developing bash compatibility, I used readline to manipulate history - I first deleted command from readline's history, then wrote the history to a file. After the program exits, if the history was manipulated, then I do history -r and I get the expected behavior. Since zsh does not use readline and its history command significantly differs from the one that can be found on bash, I'm left with no other choice but to manipulate the history file directly. However, when I do that, the changes are not reflected until the shell is restarted. I have tried to use zsh's equivalent of history -r, which is supposed to be fc -R, but I did not get the expected results. While the command gets deleted from history after running that, pressing the up arrow (in order to go back to the previous command, which should be the one that invoked the program) brings me to a seemingly random command in the history.
I'd appreciate it if someone explained the odd behavior I'm experiencing. Any pointers in the right direction are also welcome.
I have solved this problem in my Zsh history editing plugin zsh-hist by not touching the histfile directly, but instead doing everything through Zsh's own mechanisms:
Set $HISTORY_IGNORE locally to a pattern that matches the contents of the entries you want to delete.
Use fc -W to write the history to file. Because of HISTORY_IGNORE, the unwanted entries will not be written.
Use fc -p to create a new history from file.
Zsh documentation:
$HISTORY_IGNORE parameter
fc builtin command
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
Using Ubuntu 16.04 LTS to deploy my python app. Configured everything and the app is running manually. I want to automate it with supervisor, I have installed supervisor and configured it. But if I run:
Supervisor config file:
; supervisor config file
[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0700 ; sockef file mode (default 0700)
[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor ; ('AUTO' child log dir, default $TEMP)
; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket
; The [include] section can just contain the "files" setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files *cannot*
; include files themselves.
[include]
files = /etc/supervisor/conf.d/*.conf
supervisorctl reread I end up with unix:///tmp/supervisor.sock no such file
But supervisord status is running,
Anyone having an idea, please.
Running this command sudo service supervisord restart solved my issue.
Some answers suggest re-installation, which is essentially doing this
Finally solved it by reinstalling supervisor after deleting all configuration files in /etc/supervisor/conf.d/ this did the trick.
I had the same problem. After reading the man supervisorctl manual I realized the default file is /etc/supervisord.conf which in ubuntu is at /etc/supervisor/supervisord.conf. I created a symlink using:
sudo ln -s /etc/supervisor/supervisord.conf /etc/supervisord.conf
This fixed my problem.
Reason of getting this: There is multiple reasons, what I found is that my supervisor was got corrupted due to the server going down continuously by power tripping.
solution: Remove the supervisor first and then reinstall it.
Steps:
sudo apt-get remove supervisor
sudo apt-get remove --auto-remove supervisor
sudo apt-get purge supervisor
sudo apt-get purge --auto-remove supervisor
Link for the above can be found here :
https://www.howtoinstall.co/en/ubuntu/trusty/supervisor?action=remove
The Ubuntu supervisor package (3.3.1-1.1) has the configuration file in /etc/supervisor/supervisord.conf.
For some reason (I don't know why) there appears to be another configuration file in /etc/supervisord.conf and supervisorctl prefers that file.
You can either define the configuration file location explicitly to supervisorctl:
sudo supervisorctl -c /etc/supervisor/supervisord.conf reread
or just remove /etc/supervisord.conf.
Probably one of the configuration files has syntax errors.
For instance, verify if [program] clause is missing
Remove each file on conf.d directory and restart supervisor to isolate the problematic file.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have a very simple script that needs to run as su (root) without using a password.
Script
#!/bin/bash
cd /Applications/data_vis/
sudo chown -R Fabulous:admin .
I have decided to use permissions and visudo(8) to make it possible, for the script above to run with out a password.
Permissions
sudo chown root:wheel take_ownership.sh
sudo chmod 4755 take_ownership.sh
Extract from visudo file
# User privilege specification
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
%Fabulous ALL=(ALL) NOPASSWD: /Applications/data_vis/take_ownership.sh,
%ALL ALL=NOPASSWD: /Applications/data_vis/take_ownership.sh
# Uncomment to allow people in group wheel to run all commands
%wheel ALL=(ALL) ALL
I have tried many variations and a lot of the questions on this sight. However I must be missing something as it is not obvious to what I am missing or doing incorrect.
Any practical specific solutions welcome. I am using a bash shell.
sudo is used to give non-root users root priviledges for a couple of tasks.
Supposing "take_ownership.sh" is the script, which contents is listed above, the
task of gaining root priviledges is doubled:
With sudo inside the script and by setting the script suid bit and setting the ownership
to root:wheel.
This isn't necessary.
In general for security reasons setuid scripts are to prevented.
Therefore a shell may prevent the execution of such script generally.
Another reason for the problem may unsufficient rights on /Applications/data_vis/.
for the user, who executs the script (if the setuid bit was cleared as suggested
above).
Reduce the script to
sudo chown -R Fabulous:admin /Applications/data_vis
Remove the setuid bit.
Execute the script as non-root-user.
If it fails, check with dmesg for kernel entries.
Furthermore from the sudo manpage (Linux):
There is no easy way to prevent a user from gaining a root shell if that user is allowed to
run arbitrary commands via sudo. Also, many programs (such as editors) allow the user to
run commands via shell escapes, thus avoiding sudo's checks. However, on most systems it is
possible to prevent shell escapes with the sudoers(5) plugin's noexec functionality.
It is not meaningful to run the cd command directly via sudo, e.g.,
$ sudo cd /usr/local/protected
since when the command exits the parent process (your shell) will still be the same. Please
see the EXAMPLES section for more information.
Running shell scripts via sudo can expose the same kernel bugs that make setuid shell
scripts unsafe on some operating systems (if your OS has a /dev/fd/ directory, setuid shell
scripts are generally safe).
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
The postfix alias looks like this:
%omitted%: "|/var/www/rails/redmine/extra/mail_handler/rdm-mailhandler.rb --url %omitted% --key %omitted%"
The bounce message returned says
"Command died with status 127"
and
"Command output: /usr/bin/env: ruby: No such file or directory"
I ran
sudo -u postfix /usr/bin/env ruby -v
and it returned
ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2009.10
So I assume the postfix user has ruby in its path.
I changed the shebang to /usr/local/bin/ruby and it works but I would prefer to have the code match the svn for the project I checked out.
Postfix manual local(8) says about pipe aliases:
The PATH environment variable is
always reset to a system-dependent
default path
It seems that /usr/local/bin/ is only in PATH when running interactive shell. You could tweak the PATH environment variable in your OS, but I think it's better to just change the alias to something like:
%omitted%: "|/usr/local/bin/ruby /var/www/rails/redmine/...
When you execute the command via sudo you still have your own environment, therefore your own path. Postfix's local program resets the PATH to a minimum (probably /bin and /usr/bin) when invoking an external program. You can use export_environment config parameter to set a different path. More information
So I assume the postfix user has ruby in its path.
No, it means that the user you issued the sudo with has ruby in its path. A simple sudo doesn't change the $PATH.
The simplest solution for your issue probably would be to just prepend the actual ruby to your script call, something like the following (assuming your ruby lives in /usr/bin/ruby).
%omitted%: "|/usr/bin/ruby /var/www/rails/redmine/extra/mail_handler/rdm-mailhandler.rb --url %omitted% --key %omitted%"
I just started using Zsh lately for some of the integrated support in the shell prompt for my Git status etc.
When I type in:
ruby -v
to confirm the version of ruby I'm running, Zsh asks if I want to change the command to _ruby. Well after saying no at the prompt and the command completing as expected I continue to get the question at the prompt after confirming my command is correct.
I'm assuming there is a completion file or something of the sort.
Thanks
Update:
The shell is no longer trying to complete _ruby, it stopped responding after closing the shell a few times some how.
I tried to clean the file up several times but there is a "opts" variable that is 50 or more lines long and the lines are all ran together, some lines more than 150 characters. Maybe I could email an attachment to you if you still want to see it.
I sincerely apologize for the messy post.
This is command autocorrection, activated by the correct option. It has nothing to do with completion. You're seeing _ruby because zsh thinks there is no ruby command and it offers _ruby as the nearest existing match.
If you've just installed ruby, it's possible that zsh has memorized the list of available command earlier, and it won't always try to see if the command has appeared in between. In that case, run hash -rf. Future zsh sessions won't have this problem since the ruby command already existed when they started.
Sometimes, when you change your PATH, zsh forgets some hashed commands. The option hash_listall helps against this. As above, if you can force zsh to refresh its command cache with hash -rf.
You could make an alias:
alias ruby='nocorrect ruby'
It's what I did when zsh kept asking me if I meant .meteor when I typed meteor because auto-correct is still useful from time to time.
I find the autocorrect feature can get annoying at times. So I do in my ~/.zshrc,
DISABLE_CORRECTION="true"
I had the same problem even when the command is not installed.
I can solve it using the CORRECT_IGNORE variable in my .zshrc
# OPTs to enable
setopt HASH_LIST_ALL
setopt CORRECT
# Zsh variable to determine what to ignore,
# in this case everything starting with _ or .
CORRECT_IGNORE="[_|.]*"
I hope it helps to you or anyone with this issue
Sometime ago after an update, I got command auto-correction enabled which I don't want. If the same happened to you and you want to revert it, in the ~/.zshrc file you'll have make it:
# Uncomment the following line to enable command auto-correction.
ENABLE_CORRECTION="false"
or comment it as per bellow:
# Uncomment the following line to enable command auto-correction.
# ENABLE_CORRECTION="true"
Just a note, on my zsh (version 5.7.1 on macOS), the DISABLE_CORRECTION didn't work.
I saw in my .zshrc file the following two lines, which I then commented out
setopt CORRECT
setopt CORRECT_ALL
That did it for me.