I use Altera Quartus software which comes with its own Cygwin distribution and a dumb terminal which, according to the shortcut placed in my Start Menu by Altera, is run using
cmd.exe /c "c:\altera\15.1\nios2eds\NiosII Command Shell.bat"
where this batch file configures the environment for Quartus and launches bash. When I use this window to run Altera tools, their output comes out immediately (not buffered) and in color.
I also have my own Cygwin installation with an Xserver and terminals (i.e. lxterminal, mrxvt, xfce4-terminal, etc). I have adapted Altera's batch file to configure Altera's environment within my Cygwin and I can run all of Altera's tools. However, when I run these tools, their output is neither in color (not a big deal but surprising), and is buffered until the end of execution when all output appears at the same time.
Does anyone have any ideas on how to bypass this buffering?
Somehow, your tools are thinking that the output is not a terminal but a file. For files, the tool itself will create a buffer (4K on Linux). For terminals, the output is usually line buffered (i.e. the output code will collect all the characters until an end-of-line is detected and then print them all at once).
To help you further, we need more information how you "adapted Altera's batch file to configure Altera's environment within my Cygwin"
Related
I have created a small application that uses the gloss library for a GUI. When typing "cabal run [cabal file]" the project is built and run, and only prompts the GUI. When I instead go and click on the .exe file that was generated from the build, the GUI opens but so does the command prompt. I want to stop the command prompt from opening and only have the window from gloss open.
By default on Windows GHC builds console programs, which open a Command Prompt terminal if one isn’t open already. If you want to build a GUI-only program, you can pass -mwindow to the linker by giving the -optl -mwindow flag to GHC. If you’re using Cabal, you would add this flag to the ghc-options field in the executable stanza.
Beware that if you use this flag, your program will not have any stdin, stdout, or stderr file handles, so actions like putStrLn, print, and getLine will not work, since they’re equivalent to hPutStrLn stdout, hPrint stdout, and hGetLine stdin. If you want to do any logging or printing, you’ll need to open a handle yourself (e.g. a file, terminal, or socket with another program reading the other end); however, Debug.Trace will still work if you need temporary tracing for debugging.
You can find more helpful reference information in the GHC User’s Guide §16. Running GHC on Win32 Systems.
I have some basic simple two character commands to be executed in TeraTerm.
Is there a way to execute the same TeraTerm commands through a Windows command prompt? This will overcome my dependency to open TeraTerm and then running, commands. I can directly write some .bat file to execute my short commands.
Assuming that your commands are for teraterm, and not for the OS of your device connected via teraterm, you can save your commands into a .ttl file (using notepad or whatever). You can still make it work if the commands are for the OS (using a command line or whatever in the shell of the OS program connected), but you will have to make extra commands to navigate to it.
Using the .ttl file, you can make a .bat file that does two things:
cd C:\Program Files\teraterm
TTPMacro C:\[point to .ttl file]
This won't prevent teraterm from opening, because if you script involves you interfacing with teraterm at all, it'll open unless you add /V after TTPMcro. However, it will be a hands free experience.
You can find out more about deploying the macro here: https://ttssh2.osdn.jp/manual/en/macro/
And a list of all the commands here: https://ttssh2.osdn.jp/manual/en/macro/command/index.html
And if you need special characters for navigation (ctrl+s, etc), the ASCII code table is here: https://ttssh2.osdn.jp/manual/en/macro/appendixes/ascii.html
Hope that helps!
If it's only several basic commands, you can make it without the ttl file by using TTermPro in lieu of TTPMacro.
cd C:\Program Files\teraterm
TTERMPRO /C=1 (connect thru serial com 1)
TTERMPRO etc etc
The syntax for command line using TTERMPRO can be found here: https://ttssh2.osdn.jp/manual/en/commandline/teraterm.html
When compiling/interpreting a program from the command prompt, how does the command prompt know where to find the requested compiler/interpreter?
Are these files stored in a specific place or something like that? I'm just about getting a hang of high-level programming, but I find it pretty hard to wrap my head around what happens under the hood.
There are two parts: Where to find the file just from it's filename, and what to do with it.
Where files (programs) are searched if just the name is entered:
Windows (CMD):
There is a variable %PATH% which has a list of ;-separated directories, eg. C:\Windows;C:\Windows\system32;C.\somethingelse. It is saved somewhere in the registry and can be set either in CMD itself or with a GUI somewhere in the OS configs.
Linux etc. (Bash and many more):
Similar, there is a variable $PATH which can be set at least in the shell and various config files, and the entries are separated by :, eg. /bin:/usr/bin/even/more. Priority is from left to right.
Additionally, some shells (eg. Bash) cache lookup results in their own implementation-specific way (depending on the configuration), because it's faster than having to check every directory in the path variable (at least if the searched program is in the last dir, everything has to be checked).
What to do with the file once it's found:
Windows:
In Windows, everything works with the filename suffix.
.exe and some others are native programs to start.
.bat is a shell script which is executed like it's manually written to the shell.
For every other suffix, it's configurable which program belongs to the suffix (stored in the registry, how to comfortably change it depends heavily on the used Windows version). Eg. you could say that .py belongs to your Python interpreter, the a file foo.py will start the interpreter. Btw., the same suffix-program configuration is usen when a file is double-clicked in the GUI file explorer, and of course program installers can add their entries too without the user having to do it.
Linux:
For Linux, the suffix is not as important. The first relevant thing is a binary (yes/no) flag x (x like executable) which exists for each file on the file system, just like file name, creation timestamp etc.etc.
If the x flag is set to yes:
Linux tries to detect what kind of program it is from the content. The difference between a native compiled binary program and a not-compiled script of some scripting language is pretty clear.
A native linux program is started by the kernel, like expected. Additional binary program types could be configured, eg. there is the Wine software which runs some Windows programs on Linux, and one could add a specification how Windows exe`s can be recognized inside and that they should be started with Wine.
For a text file with the x flag, the next step is to look at the first line, which should start with a '#!' (called shebang), followed by the path of the interpreter (eg. #!/bin/bash). Shell scripts (like the bat files on Windows) are realized this way, but it's not limited to classical shell scripts: Nothing prevents anyone from making a #!/bin/python script which Python content (of course, Python has to be installed for this to work).
If the x flag is set to no:
Shells like bash with usual configuration won't do anything, independent if it is a real program just without flag or a jpg image etc. For the GUI file managers:
Again, the content (and possibly the file name suffix too) is inspected to get the type, like jpg images, mp3 music, C++ source code etc.etc. (Linux knows pretty many types), and then the fitting program is looked up in a list configurable by the user and/or program installations (mime file type id <-> program).
...
Note that in the case of eg. Python scripts (which are just normal text files, not something for the kernel to work with), it can be done with and without x flag: With flag and a shebang line, or without flag and a matching mime list entry. In the "without flag" case, the shebang won't hurt if it is there, because Python (and many other scripting languages) consider it a comment because of the #.
Regarding interpreters on unix-based systems, lots of scripts start with a so-called shebang or hashbang (#! on the first line of the script) that tells what interpreter to invoke, see https://en.wikipedia.org/wiki/Shebang_%28Unix%29 .
When you enter something like some-program some-arguments, the shell will look through each directory listed in the environment variable $PATH for an executable file named some-program (on Windows it's %PATH% and some-program.exe).
This is not specific to compilers and interpreters - it happens whether some-program is gcc, python, firefox or notepad.
I am running Windows 7x64 and Excel 2010x32. I call 32bit dos programs (written in Fortran) via vba using ExecCmd (a Microsoft function that waits for a command prompt process to finish). I send a command line to this function that explicitly contains the program path and the paths of the input file and output file.
This runs fine on my PC and also on a company PC running the same software (OS and Office) and for which I have general access to the C: drive.
On other company PCs, where there is not general access to the C: drive, this does not work - i.e. the dos programs do not produce an output file. On these PCs, I can still run the program at the command prompt manually. It is just that calling this command prompt does not work via Excel VBA.
Now the strange thing is that I can successfully run one of these programs by adding "cmd.exe /c" at the beginning of the command line. That would appear to be running a command prompt within a command prompt (!). The other program (which, incidentally, is quite a bit bigger) does not work at all via vba on these PCs. I need to be able to provide other employees with something that works.
Can anyone shed some light on what is happening here and suggest a work around? I could past some code, but I think the above should be self explanatory.
You're confusing the command shell with the console window. In this context, the distinction is critical.
Console-mode programs (aka "command-line programs") require a console window to provide input and output. When a console-mode program is launched from a GUI program, Windows automatically creates a console window for it (unless instructed otherwise).
The command shell (aka "Command Prompt") is cmd.exe, a console-mode program.
The important point here is that not every console window has an instance of cmd.exe running in it. When a console-mode program is launched from a GUI program, Windows automatically creates a console window but does not automatically create an instance of cmd.exe. If you want to pass a command to cmd.exe you have to do so yourself, or use a run-time library routine that does it for you.
ExecCmd does not do this; it runs the program directly. So passing cmd /c <command> to ExecCmd is not "running a command prompt within a command prompt" at all. Without the cmd /c you aren't running a command shell command, you're just launching an executable.
There are any number of reasons why the command you're passing might need to be given to the command shell. For example:
it might be a built-in command like dir or type which only exists within the command shell;
it might include redirection or pipelining operators, or environment variable substitution;
it might be a script rather than an executable.
There are other cases. If you show us the command line being passed to ExecCmd we may be able to provide more specific advice. (The fact that the same command line is apparently working on some machines is puzzling, but can't be addressed without more information.)
the background is a shell script to open the .m3u file of a web radio station. Therefore I want to know inside the script, what's the user's program to open such files. At the moment, he has to set the environment variable $PLAYER, but obviously that is not a good way to go.
Alternative: Is there a command that takes a filename and searches itself for an appropriate program to handle that file? Like file, e.g.,
open-file my_playlist.m3u
The script should be portable, it will run at least on Ubuntu, Debian and Windows/Cygwin machines.
Cheers,
This will have to be done differently on each platform. On Mac OS X the "open" command will do what you want.
In Linux it gets murky, since the desktop environment (GNOME or KDE) keeps its own list of applications to run for each file type.
There are two files you can look for in Ubuntu / GNOME that hold this info:
~/.local/share/applications/defaults.list and
~/.local/share/applications/mimeinfo.cache
Someone else hopefully knows how to do this in Windows and can chime in.
Edit: Stealing from the other answers:
Linux:
xdg-open [filename]
Cygwin:
cygstart [filename]
And for completeness, here's a link to a previous question about how to detect which operating system you are running on: Detect OS from bash Script
I'd like if there were a different answer to this but I think you'll have to check the file association configs for every desktop environment and file manager out there (so, nautilus, konqueror, thunar, mc... all in different places and in different formats AFAIK), as well as ascertaining which one of these the user is actually using...
If someone has a different idea I'm keen to hear it.