I made my own script to make testing a little faster to execute on my .NET projects.
The name of the script is TestCoverage and is located in /home/user/bin folder with executable permissions and also added to my PATH for convenience.
#!/bin/bash
echo "Collecting TestCoverage..."
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover
The script runs as expected but after it's done the terminal stops taking input. I can only press the Enter key and the cursor is blinking as usual.
Bash version 4.4.20 running on Ubuntu 18.04
I've made some testing and it seems to take input but it isn't showed to the console. The problem is not consistent, it comes and goes through different terminal sessions.
Your script (and likely the dotnet process it invokes, because echo is a shell intrinsic that usually returns within milliseconds) is probably still running and hasn't returned.
You can open another console and type ps aux -H to view the running processes - look out for some adjacent lines with TestCoverage, bash, and dotnet.
In those lines, you can see what state the process(es) are in
(RTM for further detail).
If you are running a console under X, you can first look around whether you accidentally pushed some running dotnet test ... window behind your console window. :-)
Related
I just realized that i cannot execute .sh scripts anymore on my debian.
It used to work fine. All .sh files are +x chmodded and used to work fine.
Suddenly, once i execute: ./test.sh system hangs.
I am able to stop this via ctrl+c, but script never executes.
Steps did so far was to restart my VPS.
Any ideas?
I am pretty sure shell scripts are still working on your machine, because if they weren't, you would not be able to complete any boot cycle.
If I suppose you are facing problems with your homemade scripts, then you should probably check your shebang line (#!/bin/sh for example) to see if anything unusual was used there.
New scripts are using a dispatcher to interpreters:
`#!/usr/bin/env bash` #lends you some flexibility on different systems
`#!/usr/bin/bash` #gives you explicit control on a given system of what executable is called
The difference between “#! /usr/bin/env bash” and “#! /usr/bin/bash”?
I am trying to use Sublime Text + GoSublime to do Golang development.
I am working with a webserver in Go (ListenAndServe("8000", &handler)).
The problem I have is that when I run the Go process (while another one is running), the second process doesn't work (since the port is already in use).
What I want to happen is that when I go run web.go, if one was already running, shut that down before running this one.
Sublime Text 3's build system doesn't seem to keep track of the previous execution - so I don't know the best way to terminate. When I run CTRL+B it doesn't block, it executes the build system in another thread - meaning that I can't CTRL+C before executing the next. So what I'm having to do is terminate via the command line the existing process before starting the next one.
So I'm looking for either a solution with Sublime Text's build system configuration, or perhaps even having the Go process itself check to see if one is running and killing the process.
Ideas? It's sort of annoying to swap back and forth from terminal.
Not sure if I understand the question right.
But in sublime text build console, there is tskill command which can kill active tasks initiated from the console. So you can type Ctrl+B to invoke out console and type tskill to kill the running web.go task. There are also other alias tskill <task ID>, task replay or task go. Reference is here. After that you can run other commands including go run.
What's more there is a replay command. "It is like run but attempts to cancel any active executions before running". I feel it looks like what you want.
Further, Gosublime command shell has sh command mode. It's much flexible for example type sh killall web;go run web.go or run a shell script to run that.
Hopefully it helps.
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 have a Shell command that I'd like to run in the background and I've read that this can be done by suffixing an & to the command which causes it to run as a background process but I need some more functionality and was wondering how to go about it:
I'd like the command to start and run in the background every time the system restarts.
I'd like to be able to able to start and stop it as and when needed just like one can do service apache2 start.
How can I go about this? Is there a tool that allows me to run a command as a service?
I'm a little lost with this.
Thanks
UNIX systems can handle as many processes as you need simultaneously (just open new shell windows if you're in a GUI), so running a process in the background is only necessary if you need to carry on using the current shell window for other things once you've run an application or process that keeps running.
To run a command called command in background mode, you'd use:
command &
This is a special character that returns you to the command prompt once the process is started. There are other special characters that do other things, more info is available here.
Take a look at the daemon command, which can turn arbitrary processes into daemons. This will allow your script to act as a daemon without requiring you to do a lot of extra work. The next step is to invoke it automatically at boot. To know the correct way to do that, you'll need to provide your OS (or, for Linux, your distribution).
Based on this article:
http:// felixmilea.com/2014/12/running-bash-commands-background-properly/
...another good way is with screen eg:
screen -d -m -s "my session name" <command to run>
from the screen manual:
-d -m
Start screen in detached mode. This creates a new session but doesn't attach to it. This is useful for system startup scripts.
i.e. you can close your terminal, the process will continue running (unlike with &)
with screen you can also reattach to the session later
Use nohup while directing the output to /dev/null
nohup command &>/dev/null &
For advanced job control with bash, you should look into the commands jobs bg and fg.
However, it seems like you're not really interested in running the command in the background. What you want to do is launch the command at startup. The way to do this varies depending on the Unix system you use, but try to look into the rc family of files (/etc/rc.local for example on Ubuntu). They contain scripts that will be executed after the init script.
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