I have the following problem with the fish shell on my mac. I recently figured how to modify the ~/.config/fish/config.fish to automatically run a command upon starting the terminal.
Now, I want to run a particular script that prints some ASCII art, and it works just fine on the regular terminal app (so it shouldn't be a problem with fish or the script, I think) but prints only the � character in the Hyper terminal (Hyper.is). Now the trick is, if I just run the script in the shell, it works just fine.
My question is ; does anyone know why it doesn't work when launched on startup by fish, but works fine when I launch it ?
Solved the problem - I added a very small delay to the script before printing the ASCII art, and now everything works. I think it may be because executing this immediately upon launching of Hyper messed up with a plugin I used (I'm thinking about the hyper full plugin)
Related
I recently switched from bash to zsh and now the tabstops in my Ultisnips-snippets aren't working properly anymore.
I didn't change anything in my snippet files and after I encountered the problem for the first time, I went back to bash, started vim from there and the snippets worked as intended again.
I have these to snippets
snippet ( iA
($1)$0
endsnippet
snippet mk wA
$$1$$0
endsnippet
If I run vim from bash and type mk, it will expand to
$Cursor$
(I will denote the cursor position by Cursor). Then I can type f( and it will expand to
$f(Cursor)$
If I press x and then tab it will take me to
$f(x)Cursor$
(I will call this previous step S). Pressing tab again I will arrive at
$f(x)$Cursor
Running vim from zsh however, I can still do the steps until S but if I then press tab, it will stay at
$f(x)Cursor$
and start inserting tabs after that. If I only do mk however and type something else without brackets, for example ab
$abCursor$
and then press tab, it will work as expected and get me to
$ab$Cursor
Does anybody have an idea what's going on here? What can I do if I want to keep using zsh and Ultisnips? If I run bash -c 'vim file.txt', vim will work really slowly and lag a lot, so that is not really an option.
Any help would be appreciated.
Edit: Apparently the problem has something to do with what version of vim I'm using. I use macOS and the problem I described happens when I use the default vim version. If I use a custom-compiled version of vim, it works as expected. And as it turns out I have some config file that tells bash to use the custom-compiled version, whereas zsh still uses the default one. I also tried it on my PC (running Ubuntu) and with the vim version installed there, it also worked. So I guess, I'll use my custom-compiled vim to avoid this problem...
But does anybody know, what vim setting could be responsible for this? If I'm not mistaken my custom-compiled version is just the huge-feature version of vim.
I just switched to a windows machine and I'm trying to get fish configured correctly. I installed it through the default route, as a shell selected through cygwin setup. It seems to be working fine, but when I directly access fish.exe or run fish.exe through IntelliJ, it outputs a ? before very prompt:
I googled and found this on fish documentation FAQ:
I'm seeing weird output before each prompt when using screen. What's wrong?
Quick answer:
Run the following command in fish:
echo 'function fish_title;end' > ~/.config/fish/config.fish
Problem solved!
The long answer:
Fish is trying to set the titlebar message of your terminal. While
screen itself supports this feature, your terminal does not.
Unfortunately, when the underlying terminal doesn't support setting
the titlebar, screen simply passes through the escape codes and text
to the underlying terminal instead of ignoring them. It is impossible
detect and resolve this problem from inside fish since fish has no way
of knowing what the underlying terminal type is. For now, the only way
to fix this is to unset the titlebar message, as suggested above.
Note that fish has a default titlebar message, which will be used if
the fish_title function is undefined. So simply unsetting the
fish_title function will not work
So it appears that intelliJ and cmd (fish.exe runs in cmd.exe if you access it directly) do not support setting the title bar, so they just output the character to the terminal instead. However, their suggested solution does not work. I've tried various options like echoing an empty string or a space, but nothing gets rid of that darn question mark.
Has anyone else run into this and found a solution?
Notes:
It doesn't have this behavior when using fish through mintty.exe,
most likely since that terminal supports setting the title, but I really prefer
to use the terminal inside intelliJ instead of having it in a
separate window.
It didn't have this problem when I used fish through IntelliJ on Ubuntu or MacOSX, it appears to be isolated to Windows
I'm trying to script tmux with a bash script.
Here's the line that I'm using to execute another script in the background (quotes are part of the line):
"$CURRENT_DIR/scripts/continuum_restore.sh" &
That works just fine on my machine. The problem is, it seems that the above line is *not backgrounded* for another user that uses the script. The script is executed synchronously in his case.
Interestingly, we tried backgrounding a random process from the login shell (sleep 10 &) and things worked okay in that case.
Here's a github issue the user opened.
Here's all the info I have for the user's computer where backgrounding does not seem to work:
OSX 10.10.1
bash --version is GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin14)
users' tmux version is 1.9a (if this matters)
Here's the whole script that contains the line that is not backgrounded, link. The problematic line is 56.
Ideally I'd like to first reproduce the issue consistently and then try to fix it. Here are the things I've tried to reproduce the issue (unsuccessfully):
set +m (setting this just before the line with ampersand)
stty susp undef (setting this just before the line with ampersand)
setting both of the above
The specific question I have is: what option can be used to disable backgrounding functionality in bash/shell? (so I can reproduce the above issue)
You can try to redirect output. It could prevent job to run in a background.
nohup "$CURRENT_DIR/scripts/continuum_restore.sh" >/tmp/output.log &
I want to create my own personal logfile that logs not only when I log in and out, but also when I lock/unlock my screen. Kindof like /var/log/wtmp on steroids.
To do this, I decided to run a script when I log into Ubuntu that runs in the background until I quit. My plan to do this is to add the script to .bashrc, using ./startlogging.sh & and in the script I will use trap to catch signals. That's great, except .bashrc gets run every time I open a new terminal, which is not what I want for the logger.
Is there a way to tell in Bash that the current login is a gnome login? Alternatively, is there some sort of .gnomerc I can use to run my script?
Edit: Here is my script:
Edit 2: Removed the script, since it's not related to the question. I will repost my other question, rather than repurpose this one.
Are you looking for a way to detect what type of terminal it is?
Try:
echo $TERM
From Wikipedia:
TERM (Unix-like) - specifies the type of computer terminal or terminal
emulator being used (e.g., vt100 or dumb).
See also: List of Terminal Emulators
for bash use : ~/.bash_logout
that will get executed when you logout, which sounds like what you are trying to do.
Well, for just bash, what you want are .bash_login/.bash_logout in your home directory (rather than .bashrc) These are run whenever a LOGIN shell starts/finishes, which happens any time you log in to a shell (on a tty or console, or via ssh or other network login). These are NOT run for bash processes created to run in terminal windows that you create (as those are not login shells) so won't get run any time you open a new terminal.
The problem is that if you log in with some mechanism that does not involve a terminal (such as gdm running on the console to start a gnome or kde or unity session), then there's no login shell so .bash_login/logout never get run. For that case, the easiest is probably to put something in your .xsessionrc, which will get run every time you start an X session (which happens for any of those GUI environments, regardless of which one you run). Unfortunately, there's no standard script that runs when an X session finishes.
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703