Some of my build commands use the osx command say to notify me of progress whilst I continue to work. Generally, they use a gentle female voice, but when I run the command as sudo there is a rather gruff manly voice telling what's going on.
I think it would be useful if sudo commands had a similar visual clue to their output, so maybe the output could be prefixed with * or the colour changed to bright yellow or something alike. Is there any way to achieve what I want?
Maybe I could create an alias for sudo which changes the colour of output, then continues to issue the sudo command - but I don't know how to get the colour to be changed back.
Is there any existing system to enable this tweak?
Use alias sudo="tput setaf 1; sudo".
To change the color back, simply add tput setaf 0 to your PROMPT_COMMAND (in the .bashrc)
Related
I'm trying to make my random-wallpaper script run every 15 minutes using cron and pywal to change the terminal color pallet. This is my script:
#!/bin/bash
export PATH="$PATH:$HOME/.local/bin/"
files=($HOME/Imagens/wallpapers/*)
image="$(printf "%s\n" "${files[RANDOM % ${#files[#]}]}")"
wal -i $image
And this is the cron line i'm using:
*/15 * * * * DISPLAY=:0 ~/.scripts/random-wallpaper
This works fine when i run it from the terminal and also when using cron on i3wm, but when i switched to gnome it just changes the colors of the terminal as it is suposed to using the new wallpaper as reference, but the wallpaper doesn't change. I tried using DISPLAY=:0.0, using . instead of it, and nothing works.
I need some help figuring out what the issue is.
I came across this post when I was searching for my solution to this. My initial try with wal did something similar to me in awesomewm, where the the terminal colors would change but the background wouldn't. This is what I ultimately did to fix it, though I'm sure it's not the ideal solution. Note that I'm not certain this will work for gnome, as I am bouncing between awesomewm and xmonad. But, you might be able to tweak my approach to suit your needs. I did this with the following cron line:
* * * * * /bin/wal -a 95 -i "$HOME/wallpaper/" -n; DISPLAY=:0 feh --bg-scale "$(< "${HOME}/.cache/wal/wal")"
The important part to note here is the -n flag for wal suppresses wal setting the background (not that that was your issue), but the file path still changes in the .cache/wal/wal file. Also, note that I just pass wal the directory, and it picks a random image from the directory. I then use feh to set the background, but needed to use DISPLAY=:0 to pass the environment variable. I don't know if feh will work to set the background for gnome, but in the very least using wal in this way might simplify your script and perhaps thinking about using something else besides wal to set the background may help. Perhaps you can use gsettings to set the background in gnome, but an initial look tells me others seem to have trouble setting backgrounds with gsettings and cron jobs, but I can't really speak to this as I'm not entirely familiar with how you can set the background in gnome from the terminal (besides running wal from the terminal). Perhaps this post on S.O. will assist you further for doing this in gnome if the above approach using feh doesn't.
First off:
I'm using tmux 2.5 installed via homebrew on OS X 10.12, in iTerm 2 (though the problem appears in Terminal.app as well). My tmux.conf is on Github, along with my zshrc.
The problem: Seemingly out of nowhere, I started seeing an issue with typing in the prompt. Typing keys once will display them twice, and backspacing will move the cursor forward and redraw characters already present on the line. This only happens inside of a tmux session, and not inside my "regular" terminal.
Here's a gif of the issue. In this gif, I type 1234567890, then hit backspace 9 times, and type ls. Note that 0 only shows up once, and lls with a duplicated l runs the ls command as expected.
Hopefully I just hit a weird key combo on accident, but I've been stuck on this for a while.
Thanks for any help!
Installing tmux-256color for macOS as in this guide solves the problem.
Running the following as mentioned in a github issue solved the problem for me:
brew install ncurses
$(brew --prefix)/opt/ncurses/bin/infocmp tmux-256color > ~/tmux-256color.info
tic -xe tmux-256color tmux-256color.info
infocmp tmux-256color | head
I'm also running into this issue as well. I encountered the problem similar to #artemave, by trying to change the set -g default-terminal "screen-256color" to set -g default-terminal "tmux-256color". The goal of doing this was to gain italics, per the tmux FAQ.
#taylor's answer didn't work for me, as I didn't have that command.
I managed to determine that:
The issue doesn't occur with bash
When running a blank .zshrc, backspacing creates new blank lines, but I'm not seeing the character duplication
Using tmux-256color will successfully give italic fonts
Using TERM=xterm-256color and TERM=konsole-256color does not change the above effects
Using xfce4terminal (0.8.9.1), Konsole (19.12.3), or URXVT (9.22) doesn't change the above behavior
I wasn't able to really "fix" the issue, as the even going down to a blank .tmux.conf wasn't able to change anything. Instead, I just needed to change it to anything else. xterm-256color was suggested in this issue, but I found nearly anything else would work fine.
I'll keep working on it and update this answer if I find anything else.
Edit: This tmux issue is the exact issue we're running into. I'll see if the solutions there work
https://github.com/tmux/tmux/issues/597
Edit 2: I've submitted a GitHub issue with tmux. No real results yet, but it does offer some guidance on things to check on.
The problem seems to be fixed after commenting out this line from my tmux.conf:
set -g default-command "reattach-to-user-namespace -l zsh"
I also had to manually run tmux kill-server instead of relying on just re-sourcing my conf file.
When I find some time, I'll look more into what went wrong here...
Is it just me?
I have just installed fish using brew install fish and I'm using iTerm2.
The color is absolutely unreadable. How do I change it to something nicer?
I realized my mistake was with iTerm and not with Fish.
Press CMD+i with an iTerm window open, then click the Colors tab and set it something nicer.
Not sure why this problem didn't show up before, but it seems like it was triggered by the new Fish installation.
Technically that isn't fish doing the coloring. It's the ls command. However, fish does wrap the command in a ls function which tells the command to color the output and use the colors specified by the dircolors command if it is installed. If you don't want the coloring you can create your own ls function that omits the --color=auto flag. Or you can define your own $LS_COLORS env var to keep from using the colors provided by dircolors.
Just add alias ls="ls" to your ~/.config/fish/config.fish file.
if you don't have config.fish on your fish directory, create it!
This trick will change ls command's color to white.
I have a "stock" xmonad install on Arch.
No changes to my xmonad.hs yet
I have installed dmenu.
It runs by alt-p, the default, and displays and filters as expected.
Chromium runs, but other items, like ranger, alsamixer or other tasks do not.
I am not finding anything anywhere about anyone having to do anything to get these items to run, nor anyone having any issues with doing so.
Surely, then, there is something wrong in my install.
my dmenu_run is as follows:
#!/bin/sh
dmenu_path | dmenu "$#" | ${SHELL:-"/bin/sh"} &
I would normally run terminology with bash or zsh. I have tried to alter the SHELL to /bin/bash, but to no avail.
Is there any other place I must look or items I should alter?
Such a shame as I am really liking xmonad so far, and want to get dmenu working before I start exploring xmonad.hs...
Thanks in advance
UPDATE: I have found the following
here over at Archwiki that involves changing dmenu_run and adding a .demenu_term in one's home. It seems to work, but still wonder if there was a more orthadox mechanism.
ranger and alsamixer are applications which run inside a terminal. Imagine (or try) to run ls via dmenu, where should the directory listing be printed to without a terminal?
You look for functionality which is provided either by prompt imported from XMonad.Prompt.Shell by using a convinient keybinding like
((modm .|. shiftMask, xK_c), prompt ("xterm" ++ " -e") greenXPConfig)
(described in the linked documentation) or shellPrompt where you execute
xterm -e alsamixer
or any other command, e.g.
feh path/to/image/you/want/to/open/now.jpg
instead of opening a terminal, running above with tailing & and exiting the terminal.
I'm using OSX snow leopard, for the record.
When I use emacs straight from terminal, I have a color set (e.g. for c/c++) that I'm very happy with---green on black, red comments, colored key words... etc etc. Some of this is set in my 'terminal preferences', and some is in my ~/.emacs file (see below). When I run emacs from screen, the basic color-scheme is the same (green on black), but the coloring is different (e.g. comment characters are red, but not the entire comments) -- and really annoying.
Any help would be appreciated!
In my '.emacs' file (this stops working in gnu-screen emacs):
(global-font-lock-mode t)
(custom-set-faces
'(font-lock-comment-face
((((class color) (background light))
:foreground "tomato")
)))
In my '.screenrc' file:
shell -$SHELL # colors still don't work without this
#term xterm-256color # using this doesn't fix the colors (suggested on some forums)
altscreen on
startup_message off
I thought that the command 'shell -$SHELL' in my .screenrc file made the command prompt in screen the same as the default --- it does make my command line say 'computername:/DIR/ username$' instead of just 'bash-3.2$'
=================================================================
Solution: Thanks to Greg E.
I needed to set my terminal emulator in screen to match that of my normal shell. To do this, I added
export TERM='xterm-color'
to ~/.bash_profile
For some reason, 'term xterm-color' in the '~/.screenrc' file didn't work.
My suspicion is that, while your terminal may be compiled with support for more than the standard 16 colors, your particular version of GNU screen may not be. I'm not very familiar with OSX, but on Linux I'd check whether the output of tput colors differs between a plain terminal and one running screen (I'd expect there to be some OSX equivalent if tput is not available). If it does, you may need to install (or manually compile) a different build of screen that includes support for additional colors (normally, 256 is the maximum, but 88 is also common, while 16 is the default minimum).
Edit: Ultimately, the correct solution proved to be manually setting the $TERM environment variable (see comments below).