I am writing a console application which is using some library in which (DEBUG) prints are enabled. In my main() application I am taking inputs from user. I want this user input to be separate from my library prints. I cant disable library debug prints. (The problem is library has lots of continuous prints over which it is difficult to take user input. Can I do something like creating a new tty for taking user inputs. )
dup2(2,3p) lets you duplicate an existing file descriptor (such as the one you just opened on /dev/null) onto another existing file descriptor (such as FD2, stderr). So, open /dev/null for writing and clobber stderr with it.
Don't forget to add an option to disable this though, in case you need to debug.
Related
I have a menu system that all users are automatically directed to. This is done by changing the shell attribute in /etc/passwd to point to a script that sources the profile and generally sets up the environment before calling the main program.
For example, a store manager would be like this:
strmgr:x:1234:1234:Store Manager:/home/storeuser:/opt/menu/start_menu.sh
I'm looking for a way to capture STDERR from the login process to a file that I can then interrogate in the menu script itself, displaying the important pieces as needed.
My initial thought was to add exec &2>/tmp/$$.stderr
at the top of the script but that doesn't work as I'd hoped. There are still system generated messages that are masked by the menu display. I guess they're generated before this script is called, even though I'm not using the "normal" shell and .profile start-up.
Does anyone have an idea of how to do this? I've scoured google and found nothing.
Simply like this:
exec 2>/tmp/$$.stderr
The & is a shorthand for 2>&1 (redirect STDERR to STDOUT).
I know from experience that if I try to open the same file in Vim in multiple terminals at the same time, I get an error. (Maybe because of temporary files?)
And I know from experience that if I open a text file in Python and read through it, I have to reset the pointer when I'm done.
But I've found that if I run the same Python script in multiple terminals at the same time, I don't get any error; it just successfully runs the script in both. How does this work? Doesn't Python need to read my script from the beginning in order to run it? Is the script copied to a temporary file, or something?
I know from experience that if I try to open the same file in Vim in multiple terminals at the same time, I get an error.
That's not actually true. Vim actually will let you open the same file in multiple terminals at the same time; it's just that it gives you a warning first to let you know that this is happening, so you can abort before you make changes. (It's not safe to modify the file concurrently in two different instances of Vim, because the two instances won't coordinate at all.)
Furthermore, Vim will only give you this warning if you try to open the same file for editing in multiple terminals at the same time. It won't complain if you're just opening the file for reading (using the -R flag).
And I know from experience that if I open a text file in Python and read through it, I have to reset the pointer when I'm done.
That's not exactly true, either. If you make multiple separate calls to open, you'll have multiple separate file objects, and each separately maintains its position in the file. So something like
with open('filename.txt', 'r') as first:
with open('filename.txt', 'r') as second:
print(first.read())
print(second.read())
will print the complete contents of filename.txt twice.
The only reason you'd need to reset the position when you're done reading a file is if you want to use the same file object to read the file again, or if you've opened the file in read/write mode (r+ rather than r) and you now want to switch from reading to writing.
But I've found that if I run the same Python script in multiple terminals at the same time, I don't get any error; it just successfully runs the script in both. How does this work? Doesn't Python need to read my script from the beginning in order to run it? Is the script copied to a temporary file, or something?
As I think should now be clear — there's no problem here. There's no reason that two instances of Python can't both read the same script file at the same time. Linux allows that. (And in fact, if you delete the file, Linux will keep the file on disk until all programs that had it open have either closed it or exited.)
In fact, there's also no reason that two processes can't write to the same file at the same time, though here you have to be very careful to avoid the processes causing problems for each other or corrupting the file.
terminal is just running the command you said it to execute, there is no pointer or anything
you jus
i'm aware the it is possible to set the stdin to the content of file defined in the project profile. What i'd want though, is the ability to change the stdin while debugging. Is there any way to do this on a linux system?
Basically i need this because my next input to debuggee is depending on one of it's former outputs. This means i'm unable to set the right stdin content before i start debugging.
In fact i need to set it while i am debugging!
Thank you very much!
I'm running an Adobe After Effects project via subprocessing and I'm trying to find a way to write to Stdout or Stderr from within AE, so that I can communicate to the parent process. In other words, is there any way to write to Stdout from Extendscript?
Yes I do know about $.writeln() but that writes to the Extendscript Toolkit console, not stdout and is therefore unreadable by another process.
A little late but yes. There is a writeConsole() global function... So you use that instead of the one within $. Also there are write() and writeLn() global functions that write to info panel.
I need to test a program that creates temporary file. When run finishes it deletes the file. How can I check it file has be created and deleted.
I am thinking about sending some signals to process (like Ctrl-Z) to suspend it and check but should be simpler ways.
I am using bash in Linux.
Since you don't have access to the program code, then you could use the strace tool to intercept all the system calls issued by the process. Then with simple greps you can look for file creation, deletion and all related operations. Probably you have to use the "-f" option to make sure everything is logged including the operations performed by any process's child
If you can, with some certainty, know when the file will be created you can use the link command to hang onto the file. For example, in the code you are testing there is a sequence like:
open some temporary file for writing
# do stuff
write stuff to open file
close file
unlink file
If, in between the open and unlink in the tested program, you can run
ln the_temp_file my_temp_file
then when the unlink occurs, the tested program will have no idea that you have a hard link to the file so it didn't get removed from the file system.
This will not work for symbolic links ln -s so your link will need to be on the same physical device.