I would like to enable zsh to autocomplete modules for yast2 (an OpenSuSE control panel), but it seems to already have some things defined. I can run
compctl -k "(hello world)" nonexistantprogram
just fine, but
compctl -k "(hello world)" yast2
doesn't work at all. Some things for yast2 seem to be already defined, namely the "-" options: --fullscreen, --geometry, --list [submodules], etc.
Even if for those who don't use OpenSuSE: Are there any flags to compctl to make it override previous settings? Thanks very much in advance.
Most likely, your system is using the newer compsys system rather than the older compctl system. See man zshcompsys and man zshcompwid (and man zshcompctl).
The completion function for yast2 is probably in this file (or similar path):
/usr/share/zsh/functions/Completion/Linux/_yast
Related
I've ubuntu 16.04 and i've installed perl 5.8.7,5.18.2 both with threads activated, and 5.18.1 without threads.
The purpose was to use a version of Perl with threads instead of forks as i've mutiple scripts already done with threds and forks is not a proper multi-threading models (it just forks processes).
The first problem i get is when installing modules via cpanm -fi [name_of_module] command. As a matter of fact the command doesnt' return anything at all! just 'Perl'. The same fact happens when i'm traying to instal wathever modules i desire using in my scrips.
I think this problem is linked with the fact i'm able to use ''treads'' just when i run the scripts without sudo (e.g.perl [name_of_the_script]), while when i run it with 'sudo perl [name_of_the_script]' says 'the current version of Perl doesn't support threads'!
That's quite strange.
The perlbrew enviroment veriables are set up correctly and when i type ''which perl'', the system poits to the new-version directory as expected.
Dont' know how to proceed
I see that you posted several question in one paragraph. I'll try to answer the onse that I could.
cpanm -fi XXX does not "return anything at all"
I'm not sure I get this part. If XXX failed to be installed, there should probably be some error messages on the screen. The fact that perlbrew list-modules prints nothing but Perl implies that probably nothing is installed.
It could be that your cpanm execuateble is implicityl installing stuff for system perl instead. You could verify this by checking the first line of head =cpanm. If it is not #!/usr/bin/env perl, it is probably wrong. You want the one installed by: perlbrew install-cpanm
sudo perl
I wonder if you PATH is actually correctly set -- Running perl -V after perlbrew use 5.8.7 can show you enough version information and therefore tell you whether perlbrew itself is working properly.
You probably also need sudo -E perl instead. sudo reset env vars unless you ask it not to (the -E option), and PERL5LIB is probably needed.
My gnome-terminal is broken, so is zim and many other programs, the xfce-terminal does not show characters like ö ä or ü. All of them show problems with the locale. I think the problems stems from ill-configured locale settings. For typing "locale" the xfce4-terminal prompts
LANG=C
LC_CTYPE="C"
LC_NUMERIC=aa_DJ.UTF-8
LC_TIME=aa_DJ.UTF-8
LC_COLLATE="C"
LC_MONETARY=aa_DJ.UTF-8
LC_MESSAGES="C"
LC_PAPER=aa_DJ.UTF-8
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT=aa_DJ.UTF-8
LC_IDENTIFICATION="C"
LC_ALL=
This is not what I want. My /etc/locale.conf is set to
LANG=de_DE.UTF-8
My /etc/locale.gen is uncommented such executing "locale-gen" prompts
de_DE.UTF-8... done
de_DE.ISO-8859-1... done
en_US.UTF-8... done
en_US.ISO-8859-1... done
When looking at the environment variables my "locale" produces, it doesn't wonder me too much, that nothing is working as supposed. I don't know why there is "aa_DJ" in these variables, I don't know the language (to be precise, I am not sure which language that is, maybe I speak it ...). However, I really don't know where to change the environment variable permanently (Without putting it in .bashrc) . I tried grepping it in my home folder and after that in root (Recursive on --> grep looked everywhere), but I couldn't find anything.
So my question is: Where or how are these variables defined and how can I change them? I can't find anything that explains it to me. I am aware that there are several people asking similar questions, I tried those solutions but they seem to have different problems (or they solve it with hacking something into .bashrc, which doesn't do the trick here and is not a very meaningful way).
So, the locale you have there seems to be:
Afar - DJIBOUTI (DJ) (aa_DJ)
So, after running locale-gen you need to run localectl list-locales and identify the locale you need.
Finally run:
localectl set-locale LANG=de_DE.UTF-8
NOTE: The German page for locale in Arch linux seems to be outdated
As I found out now, I missed to give an information that might have been useful and which helped me to solve the question. I use the gnome3 desktop env. Gnome3 has its own setting for the locales that overwrites the system standard (and is not saved in plain text I assume, otherwise I should have found it with grep). The solution was to correct the gnome setting via
gsettings get org.gnome.system.locale region 'de_DE.UTF-8'
I am having a problem* with the bash that comes with Git for Windows.
But I don't even know where to start looking/googling/reporting the bug.
It seems that all of MINGGW64 (= MinGW-w64?), MSYS, Cygwin and maybe Mintty are somehow involved, but I don't really understand the relationships between them.
Which one is providing the terminal?
* It ignores the VT100 escape sequence sent by echo -e '\033[?1h' which should put the cursor keys in "application mode" (= make them send <ESC>OA instead of <ESC>[A).
I assume you have already found, if not
https://mintty.github.io/
I've got a problem with ANSI escape codes in my terminal on OpenSuse 13.2.
My Makefile use to display pretty colors on OSX at work but at home when I use it I get the litteral termcaps such as \033[1;30m ... \033[0m
I know close to nothing about termcaps, I just found these escape characters that seemed to be working fine ! The strangest is that both my OSX and Linux terminal are configured with TERM=xterm-256color so I really don't know where to look for the correct setting I'm currently missing on Linux.
TL;DR: How to get escape codes such as \033[1;30m working in Konsole with xterm-256color ?
Edit: Here's a snippet of the Makefile I am talking about:
\Here's a snippet of the Makefile I am talking about:
# Display settings
RED_L = \033[1;31m
GREEN_L = \033[1;32m
GREEN = \033[0;32m
BLUE = \033[0;34m
RED = \033[0;31m
all: $(OBJ_DIR) $(NAME)
$(OBJ_DIR):
#mkdir -p $(OBJ_DIR)
$(NAME): $(OBJ)
#echo "$(BLUE)Linking binary $(RED)$(NAME)$(BLUE).\n"
#$(CC) -o $# $^ $(LFLAGS)
#echo "\t✻ $(GRAY)$(CC) -o $(RED)$(NAME)$(GRAY) object files:$(GREEN) OK! √\n$(NC)
The example which you gave does not rely upon the setting of TERM (unless it is going someplace other than the terminal, e.g., via some program which interprets it such as the ls program, which has its own notion about colors). It would help if you quoted the section of the makefile which uses the escape sequences. Without that, we can offer only generic advice, e.g,. by assuming you have an echo command in the makefile.
The place to start looking is at the shell which your makefile uses. One would expect bash to be the default shell on OpenSUSE. But suppose you are actually using some other shell which happens to not recognize the syntax you are using, and trying to do something like
echo '\033[1;34mhello\033[m'
To help ensure that you are using the expected shell, you can put an assignment in your makefile, e.g.,
SHELL = /bin/sh
This assumes that /bin/sh itself is going to work as intended. However, that is commonly a symbolic link (for Linux) to the real shell. If so, one possible solution would be to change the real shell using OpenSUSE's update-alternatives feature to change the shell to bash (or zsh).
For additional information, see the discussion of SHELL in the GNU make manual.
Reflecting comments on the version of make -- GNU make 4.0 is known to have incompatible changes versus 3.81, as noted in the thread GNU Make 4.0 released on LWN.net. In particular, there are several comments relating to your problem, starting here.
However, checking a recent Fedora, it seems that the problem really is that the default behavior for echo has changed. As noted in other discussions (such as Why doesn't echo support “\e” (escape) when using the -e argument in MacOSX), this was done to improve POSIX compatibility. You can get your colors back by adding a -e option to the echo commands.
I finally found the solution:
the problem was I used echo instead of echo -e which seems to be the default behaivour on Mac OSX.
Thanks for your help though, it lead me to good lectures :)
This is about me being stressed by playing the game "type a command and remember to prepend sudo or your fingers will get slapped".
I am wondering if it is possible somehow to configure my Linux system or shell such that when I forget to type e.g. "sudo apt-get install emacs", instead of just telling me that I did something wrong, gksudo would get launched, allowing me to acknowledge my credentials and get on moving. Just like UAC does on windows.
Googling hasn't helped me yet..
So is this possible? Did I miss something? Or am I asking for a square circle?
Edit 2010 July 25th: Thanks everyone for your interrest. Unfortunately, Daenyth and bmargulies answers and explanations are what I anticipated/feared since it was impossible for me to google-up a solution prior to submitting this question. I hope that some nice person will someday provide an effective solution for this.
BR,
Christian
Linux doesn't allow for this. Unlike Windows, where any program can launch a dialog box, and UAC is in the kernel, Linux programs aren't necessarily GUI-capable, and sudo is not, in this sense, in the kernel. A program cannot make a call to elevate privilege (unless it was launched with privilege to begin with and intentionally setuid'd down). sudo is a separate executable with setuid privilege, which checks for permission. If it likes what it sees, it forks the shell to execute the command line. This can't be turned inside out.
As suggested in other posts, you may be able to come up with some 'shell game' to arrange to run sudo for you for some enumerated list of commands, but that's all you are going to get.
You can do what you want with a preexec hook function, similar to the command-not-found package.
There's no way to do this given the current linux software stack. Additionally, MS has a patent on this behavior -- present a user interface identifying an account having a right to permit a task in response to the task being prohibited based on a user's current account not having that right.
I don't think this really works in a general way (automatically deciding which application needs admin rights). However you could make aliases like this for every application:
alias alias apt-get='gksudo apt-get'
If you now enter apt-get install firefox the gnome asks for the admin password. You can store the commands in ~./bashrc
You could use a shell script like the following:
#!/bin/bash
$#
if [ $? -ne 0 ]; then
sudo $# # or "gksudo $#"
fi
This will run a command given in the arguments with a sudo prefix if the command came back with a non-zero return code (i.e. if it failed).
Use it as in "SCRIPT_NAME apt-get install emacs" for example. You may save it somewhere in your $PATH and set it as an alias like this (if you saved it as do_sudo):
alias apt-get='do_sudo apt-get'
Edit: That does not work for programs like synaptic which do work for non-root users but will give them less privileges. However, if the application fails when invoked without root privileges (like apt-get does) this works fine.
In the case where you want to always run a command as root but might already be root, you can solve this by wrapping a little bash script around it:
#!/bin/bash
if [ $EUID = 0 ]; then
"$#"
else
gksudo "$#"
fi
If you call this something like alwaysroot.bash and place it in the right spot on your PATH, then you can call your other program like this:
alwaysroot.bash otherprogram -arguments...
It even handles arguments with spaces in correctly.