I have a source code that runs perfectly fine on Ubuntu, it does some copumtations, and at some points it beeps like this
system("beep -f 400 -l 500");
On Ubuntu I had to do
apt-get install beep
However, I migrated to OpenSuse (not my choice) and now I get this message "sh: beep: command not found", as the command and package are obviously different.
Does anybody know hot to trigger the system beep sound and define the duration and frequency? I have been able to find only one way to change the parameters
setterm -bfreq 500 -blength 500
, but no way to actually trigger the system bell (beep). The following things don't work
echo ^G
echo -e "\a"
PS - the system Bell is enabled at
Configure Desktop -> Application and System Notifications -> System Bell
and you can actually play with this
So, I did what #fvu proposed.
However, one needs to have sudo rights, to do so, otherwise (e.g. at my work-place we don't have sudo rights) there is this output message
Could not open /dev/tty0 or /dev/vc/0 for writing open: No such file or directory
In this case, you should:
sudo chmod 4755 /usr/bin/beep
as proposed here
I noticed that on my OpenSuse 12.3 system, the bell is working in xterm or gnome-terminal, but not in konsole or xfce4-terminal.
If the same applies to your system, then maybe a work-around could be creating a shell script called "beep" which calls xterm and rings the bell:
#!/bin/sh
xterm -e "echo -e '\a'; sleep 1"
Related
I am training myself on Linux with a Raspberry Pi 400 (OS: Raspbian) and I would like to setup my personal config file for apps (notably the Terminal in Zsh). I am able to setup my config onto the terminal with the following:
$ cd .dotfiles
$ ./export.sh
$ cd zsh/
$ source ./zshrc
The problem comes when I quit the terminal or if I open a new terminal or if I reboot the computer, the config is not "saved".
I am not an expert, but for changing bash to zsh and maintaining it as default shell language, I did the following:
$ nano /etc/passwd
and changed the following line from :
pi:x:1000:1000:,,,:/home/pi:/bin/bash
to:
pi:x:1000:1000:,,,:/home/pi:/bin/zsh
This move managed to get me zsh from start every time now. I am wondering if i can directly source my .zshrc with the same technique ... Or would you have any better idea?
I would like to avoid repeating the sourcing steps at every start in the terminal ...
I can do this in Cygwin, adding time Command
USER#USER_PC ~
$ time ./HelloWorld
shows smthing like
Hello World!!!
real 0m0.270s
user 0m0.270s
sys 0m0.270s
I've deployed an similar C/C++ Project #NetBean7.2 #Win 7.
It shows error message at Run time, Only when I add time Command ,like:
time "${OUTPUT_PATH}"
,at the Text Field of Projcet_file-> R_Click -> Properties -> Run -> Run_Command:
,and default value ${OUTPUT_PATH} only.
Error message is
C:\ProjectFolder\time does not exist or is not an executable
,seems that NetBean consider time as an excutable
Any better ways to solve it??
full command to bash needs to be in quotes if calling from cmd shell
bash -c "time ls"
time is a builtin command of bash. On my cygwin installation the proper command is:
c:\cygwin\bin\bash -c time
You have to adjust the path to bash.
I'm having trouble getting 256 colors to work using emacs 23.1.1 connecting using PuTTY and screen. Server is running CentOS 5.6.
In my PuTTY config, my terminal-type string is set to xterm-256color. In my .screenrc I have term xterm-256color Once in screen tput colors gives me 256, echo $TERM gives me xterm-256color, but once I start emacs M-x list-colors-display only gives me 8 colors.
Not sure what the problem is.
Thanks.
I hit the same problem.
To fix this problem, just add this to ~/.bashrc (yes,I use bash)
# -----------
export TERM=xterm-256color
export TERMCAP=
# ------------
run screen and emacs in an screen window. it's ok now.
versions:
bash-4.2.45
emacs-24.3_10
Screen version 4.00.03 (FAU) 23-Oct-06
Your ~/.screenrc should read:
term screen-256color
(this shouldn't be mixed up with xterm-256color)
Putty has a setting to allow 256 color mode. It's under Window/Colours, labeled "Allow terminal to use xterm 256-colour mode". Make sure it's checked.
After you load emacs, you can confirm the TERM value emacs is using with:
(assoc 'tty-type (frame-parameters (car (frame-list))))
It should be (tty-type . "xterm-256color").
Looking at your post and your responses to others, it sounds like your problem is... screen. To test my hypothesis, try this ...
$ wget http://www.frexx.de/xterm-256-notes/data/256colors2.pl
$ chmod 755 256colors2.pl
$ ./256colors2.pl
... if you see 256 colors in the shell, but not in screen, the problem is screen. And, even if there are other problems, you are going to have to fix screen in order to have any hope of seeing 256 colors in emacs ;)
I recently fixed this situation for myself on a system where I don't have sudo by building a personal copy of screen. Screen is small and it is no big deal to do ... and, IMHO, emacs w/256 colors is well worth the bother.
On Linux 2.6.x I did this:
$ wget ftp://ftp.gnu.org/gnu/screen/screen-4.0.3.tar.gz
$ tar -xf screen-4.0.3.tar.gz
$ cd screen-4.0.3
$ ./configure --prefix=$HOME --enable-colors256
$ make
$ make install
Test the new screen out with ...
$ ~/bin/screen
$ ./256colors2.pl
... if it works, put this in your ~/.bashrc:
PATH=~/bin:$PATH ; export PATH
The screen I ended up with reports being an earlier version ...
$ ~/bin/screen -v
Screen version 4.01.00devel (GNUdf0777e) 2-May-06
... than the version on my system:
$ /usr/local/bin/screen -v
Screen version 4.00.03 (FAU) 23-Oct-06
But while they both claim to support 256 colors...
$ tput colors
256
Only the new build really does. Yeah!
I had similar difficulties, I believe both of these lines were required for screen, putty, and emacs to get along with 256 colors.
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
term xterm-256color
You may also need this line too.
defbce "on"
Speak up if that's still not enough.
Try using emacs in daemon mode instead (emacs --daemon), and open emacsclients (emacsclient -t) instead of using screen/tmux. This will give you one less variable to handle in debugging this.
I was having a similar problem with putty and screen, though not using emacs. Following ataylor's response, I went to Window/Colours in Putty. In there I found and checked 'Use system colours'. This fixed my issue.
I have a 32-bit desktop, where my copy of emacs is running.
I'd like to be able to debug a program running on a very stripped down qemu 64 bit virtual machine.
The virtual machine has an ssh port 24054, which gives me passwordless root access, and it does have gdb installed.
And it has the directory which my desktop calls ~/myco/chip_test mounted as /9p
So if I make a hello.c file in ~/myco/chip_test,
then go to the 64 bit machine in which the VM will run, and compile it with:
$ gcc -o hello -g hello.c
then start the virtual machine, and on my 32-bit desktop run
$ ssh -p 24054 root#anvil 'cd /9p && gdb ./hello'
Then gdb runs perfectly in command line mode in a window on my desktop.
So now of course I want it to run under emacs, because the command line gdb is a bit hard to read, and I'd like to see my cursor stepping through the file, and have windows with watch variables and so on.
So I try M-x gdb
Run gdb(like this): ssh -p 24054 root#anvil cd /9p && gdb --annotate=3 ./hello
And I get a debugger window up in emacs and everything looks right, in fact I can even set and remove breakpoints by clicking in the fringe of the ~/myco/chip_test/hello.c file in my local emacs, which is the same file as what gdb sees as /9p/hello.c, but the moving cursor doesn't appear or move around, so the whole thing is fairly useless.
So I think that emacs/Gud doesn't quite realise that ~/myco/chip_test/hello.c is the file that the debugger thinks is /9p/hello.c, although obviously something interesting is happening since I can set breakpoints, and so I wonder if there is a way to get one or another programs in the loop to translate the filenames so that everything just works.
Any ideas, or am I just going about this all wrong?
You'll get much better results if you either
mount /home/<user>/myco/chip_test on /home/<user>/myco/chip_test in the
VM (so the source paths match exactly), or
run gdbserver in the VM, and connect local GDB to it.
I have script lets say:
C:\foo.bsh
I want to be able to run this command via the windows run command:
Start -> Run
Windows Key + R
and type something small like 'foo' and hitting return.
However, I do not want a cmd prompt to be visible. This script does some preprocessing for an IDE. I do not want the cmd prompt to be open for the lifetime of the IDE process.
I have tried:
1) Creating a bat file with the following contents:
c:\cygwin\bin\bash --login "C:\foo.bsh" (this fails because it keeps a cmd open)
2) Converting the above bat file to an exe using bat_2_exe_converter (does not make the cmd silent)
thoughts?
EDIT: The solution so far suggests something to type from an actual cygwin shell. I am trying to get a faster solution by having something short I can type in the Windows run command. Also, the nohup command; exit doesn't automatically kill the box - however I can manually kill it without killing the IDE process. The run command accepts shortcuts (.lnk's), bat's, exe's.
Try the run.exe command of cygwin. It is a big install, a complete unix environment for your Windows machine. Suppose you installed it at c:\cygwin\.
No mystery, just run c:\cygwin\bin\run.exe <your command here> and you will have your no dos window execution.
You can run it from any DOS window (run cmd.exe from the start menu). You don't need to run it from cygwin.
To make it easier, append C:\cygwin\bin to your %PATH% env var (My Computer → Properties → Advanced → Environment Variables) (Kudos to Felipe Alvarez comment).
Now you can just type
c:\cygwin\bin\run.exe "C:\foo.bsh"
You must create a link in your Start Menu with this command so will be able to run it with Win-R.
Here is the man page of the runcommand:
$ man run
RUN(1) run 1.3.0 RUN(1)
NAME
run - start programs with hidden console window
SYNOPSIS
run [ -p path ] command [ -wait ] arguments
runcommand [ -p path ] [ -wait ] arguments
DESCRIPTION
Windows programs are either GUI programs or console programs. When
started console programs will either attach to an existing console
or create a new one. GUI programs can never attach to an exiting con‐
sole. There is no way to attach to an existing console but hide it if
started as GUI program.
run will do this for you. It works as intermediate and starts a pro‐
gram but makes the console window hidden.
With -p path you can add path to the PATH environment variable.
Issuing -wait as first program argument will make run wait for program
completition, otherwise it returns immediately.
The second variant is for creating wrappers. If the executable is
named runcommand (eg runemacs), run will try to start the program (eg
emacs).
EXAMPLES
run -p /usr/X11R6/bin xterm
run emacs -wait
runemacs -wait
run make -wait
AUTHORS
Charles S. Wilson
Harold L Hunt II
Jehan Bing
Alexander Gottwald
Version 1.3.0 November 2005 RUN(1)
You can use either...
c:\cygwin\bin\bash -l /path/to/script_to_interpret.sh
...or...
c:\cygwin\bin\bash -l -c /path/to/executable_script.sh
Note: the -l flag tell bash to "act as if it had been directly invoked by login" and use Bash Startup Files. This is important in that it sets your $PATH and other things you rely on when you launch a cygwin terminal. If you don't include -l or --login you will get "command not found" when you try to call anything except of a bash builtin.
The difference between the 2 is like the difference between doing...
bash script_to_interpret.sh
...and...
./executable_script.sh
...in *nix. The former interprets the script using bash. The latter executes the script (only if it has chmod +x executable_script.sh) and interprets it according to its "shebang" line. The latter method is also what you want to do if your executable is not a script at all, like a *nix binary compiled from source.)
It has been bugging me for a while I couldn't find the solution for this, but I finally got the right mix together.
You can simply do the following if you have cygwin on your PATH:
run bash test.js
If cygwin is not on your path, you can do this:
c:\cygwin\bin\run.exe -p /bin bash test.js
If you are looking for more control over the created window (maximize, etc) it looks like you can use cygstart also.
Sources:
- neves answer above (though that wasn't enough by itself for me personally to figure it out)
- http://cygwin.com/ml/cygwin/2008-09/msg00156.html
As the terminal can't close while your script is still running, try the command:
"nohup C:\foo.bsh; exit"
This way your script will be backgrounded and detached from the terminal, and it should exit quickly so the terminal goes away. I think that the window may still 'flash' with this approach, but the results should be better than what you're getting.
I'm running Cygwin64 and the xwin server link points to:
C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
This creates an icon AND a notification on the taskbar. I don't like that. The icon is rather useless, the notification has all your menu options from .XWinrc.
So... I wrote a .vbs script to silently run this command and make the icon go away:
Set objShell = CreateObject("WScript.Shell")
objShell.Run("C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe"), 0
Another imperfect possibility is to run the script via a shortcut and set the shortcut's Run option to "minimized".
Go to the directory where you have installed cygwin(on my machine it is c:/cygwin64/bin)
Once there simply type "bash.exe"