I am running a local development environment from the command line with one GNU-screen terminal running a text editor and the other running a continuous build process (Expo).
I want to know if changes made to a file with a text-editor in one GNU-Screen terminal immediately take effect in another terminal with the ongoing process, or if GNU-Screen waits for the process to end before updating the file system?
If not, is there a program or GNU-screen option that will allow this to occur so I don't have to restart the build each time I make a change?
Changes to files take effect as soon as the file is written to disk.
You can verify this as follows:
In screen one, write a file change to disk.
In screen two, view your change.
Related
Functions like endpointvolume and waveoutSetVolume only works for the application itself, and not the entire computer. Im looking for help, at finding options for code that will:
Control the master volume (The whole pc volume not only one application)
When opened (exe file) the code will place it self in the startup folder on the pc. I have thought of setPathway, but couldn't get it to work.
You can use SetMasterVolume(). As for making it start every time, see here: Add Application to Startup (Registry)
I'm learning how to use ncurses and I'm in a weird situation.
It seems my output can't go over 24 lines.
Moreover, whenever I run my software, and the execution finishes his job, my terminal stops working as before, and I have 2 different situations:
if I've launched my run from a line behind line 24 I can use the terminal, but if I keep scrolling when at the last line of the window, nothing more happens: all input and output keep happening in the last line, without any new line appearing at enter pressure.
if I've launched the run above line 24 the terminal will only become 24-lines high.
Both situations require me to reset the terminal, then everything works again.
I'm on MAC OSX machine.
There is a problem with the screen-size:
The easiest one to see is if you has LINES environment variable set to 24. The use_env manpage gives some clues about that.
The reason why it sounds like a problem with screen-size is that the description of the problem suggests that the program is setting the scrolling region to 24 lines.
If there is no problem with LINES, then a place to check is by running stty -a to see what the operating system supposes the screen-size to be. That is reported on the first line of stty's output as "rows".
In some cases (for instance in remote network connections), it is possible to have a session where the remote host cannot obtain the screen-size. As a workaround, you could run the resize program (an xterm utility) to update the operating system's notion of the screen-size.
By the way, your other question NCurses not restoring terminal behavior appears to be a duplicate of this. You should consolidate your questions into a single one which provides enough information for someone to offer useful information about the problem.
My program needs 2 system reboots to complete its work.
I want to use HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce registry key to autorun my program.
Sequence of operations:
Write itself to RunOnce key
Reboot
Autorun and do some stuff.
Write itself to RunOnce key
Reboot
Complete work
But MSDN article says: "A program run from any of these keys should not write to the key during its execution".
How can I start my program automatically after second reboot?
After first reboot: how my program can ask system to autorun it after reboot if it is forbidden to write to RunOnce because program already run from RunOnce?
The easiest solution is to point the autorun to a batch file. You can alter the batch file anyway you like between reboots.
The better solution is of course to eliminate at least one of those 2 reboots. Even if you're installing a new file system driver, one reboot should suffice.
At exit of your application A you can start a new application B to add the original application A to RunOnce. Application B can even the same as A but run with a command line switch to do RunOnce registration only and bypass the normal execution path.
I want to be sure that the following will not compromise my process:
The Solaris program writes heavily to stdout (via C++ wcout stream). The output serves for tracing, so during testing and analyisis the programmer/tester can easily observe what happens. But the program is actually a server process, so in the production version it will run as a demon without attached console and write all the trace output to files.
I assume that stdout is redirected to nul for a program without console, in this case I guess all is fine. However I want to be sure that the stdout output is not buffered somewhere such that after sufficient run-time we could have memory or disk space problems.
Note: we cannot redirect the trace output to a file because this would grow too large. Instead our own file tracing mechanism makes sure that new files are created and old ones deleted to always keep a certain amount of tracing and not more.
That depends how the daemon is started, I guess. When the daemon process is created, the streams have to be taken care of somehow (for example, they need to be detached from the current process, least the daemon would have to be terminated when the shell from which it was started manually exits).
It depends on how the daemon is started. If it's started as a cron job,
the output will be captured and mailed to whoever owns the crontab
entry, unless you redirect the output in the command line. (But
programs started as cron jobs aren't truly daemons.)
More generally, all processes are started from another program (except
the init processes); most of the time, that program is a shell (even
crontab invokes a shell to start its jobs), and the command is given
as a command line. And you can redirect the output anywhere you please
in a command line; /dev/null is a popular choice for cases like yours.
Most daemons are started from an rc file; a shell script installed
under /etc/rcn.d. Just redirect your output there.
Or better yet, rewrite your code to use some form of rotating logs,
instead of standard out.
I have a Native WinApi C++ Application that finds media(.wmv, .mp3 etc.) files in a specified directory & creates random playlists. The first time the application is run(& only the first time) I want to prompt the user to specify a 'home' directory that the Application will always check for media files & create a playlist from.
My Problem: I dont know of a way how I could determine when the Application is run for the 1st time?
Is there a standard way, maybe a Win32 function that I can use to detect when the Application is run for the 1st time?
Some ideas I have come up with are: (but they seem like hacks or overkill(installer idea))
The application .exe is 322kb(which is tiny & doesn't require an
installer right?) in size so I could create an installer (I was
thinking if someone is installing the application then I know its the
first run & I can prompt them then).
I could have a text file(or xml) called appData.txt & have the 1st
line where I store the home path directory. So "home_path=undefined",
on application run, I look in the text file, if the home_path ==
undefined then I prompt them to specify a home path if its not undefined then I read that directory for media files.
Any ideas of how I can determine when my Application is run for the very first time?
In the installer you could create a registry value for your program.
Then when you start your program, check the registry value.
When you run the program for the first time update that value to so you know it's been run already.
I would use the text file because you are going to have to store the user's directory somewhere anyway, might as well use it for first run detection as well. It has the added bonus that if the file is deleted, you will know that you have to prompt the user again since you no longer know what their home directory is.
You can set some registry value when your App runs for first time and check it on every run. If it is already set then App was already run. If not - set it.
Create a log file on first run. If it exists, then it's not the first time.
try
{
// open log.txt
// do second time run logic here
}
catch(file does not exist)
{
// create log.txt
// first run logic here
}