This question already has answers here:
Confused about stdin, stdout and stderr?
(11 answers)
Closed 5 years ago.
I'm trying to understand stdin stdout and stderr.
I see them used in people's code all the time and I can't understand exactly what they are. I am assuming that they have something to do with input/output but have been searching for an explanation online and can't find one. Does anybody know of a good link with an explanation or if it is simple enough to explain it would be a great help to me.
Since I am learning Python 3, examples in that would be helpful.
sys.stdin
sys.stdout
sys.stderr
File objects used by the interpreter for standard input, output and errors:
stdin is used for all interactive input (including calls to input());
stdout is used for the output of print() and expression statements and for the prompts of input();
The interpreter’s own prompts and its error messages go to stderr.
For your more understanding:
>>> import sys
>>> for i in (sys.stdin, sys.stdout, sys.stderr):
... print i
...
<open file '<stdin>', mode 'r' at 0x103451150>
<open file '<stdout>', mode 'w' at 0x1034511e0>
<open file '<stderr>', mode 'w' at 0x103451270>
mode r means reading and mode w means writing
Does this explain it well enough?
sys.stdin
sys.stdout
sys.stderr
File objects corresponding to the interpreter’s standard input, output and error streams. stdin is used for all interpreter input except for scripts but including calls to input() and raw_input(). stdout is used for the output of print and expression statements and for the prompts of input() and raw_input(). The interpreter’s own prompts and (almost all of) its error messages go to stderr. stdout and stderr needn’t be built-in file objects: any object is acceptable as long as it has a write() method that takes a string argument. (Changing these objects doesn’t affect the standard I/O streams of processes executed by os.popen(), os.system() or the exec*() family of functions in the os module.)
To clairify
if I tell the python shell to do a print:
print 'what is your name?'
"what is your name" will go to stdout, whatever that is. If you haven't made any redirects that's by default the terminal you're using. You can interact with the standard streams in various different ways, for example:
sys.stdout.flush()
Tells the python shell to force any buffered information that I've printed to go to stdout right away.
Related
I wrote the following code in the file "orgin.lua"
if test==nil then
print(aa["bb"]["cc"]) -- to produce a crash
end
print(1120)
when it crash ,it will generate the following information:
lua: origin.lua:3: attempt to index global 'aa' (a nil value)
In order to prevent decompilation and make sure the code is safe,I use the following command to convert my code:
luac -o -s test.lua origin.lua
I know the argument -s is strip debug information, then it do not show the number of rows when crash:
lua: ?:0: attempt to index global 'aa' (a nil value)
but how to bring debugging information when encryption then lua code use luac?Is there any solution?
There is no way to do this built into Lua, but there are some work-arounds.
If you only need line numbers, then one option is to leave the line numbers in the chunk. Line numbers are not that useful for reverse engineering (unluac currently doesn't use them at all), so it shouldn't affect security. Lua doesn't provide an option for this, but it is easy to modify Lua to leave them in when stripping. From ldump.c
n = (D->strip) ? 0 : f->sizelineinfo;
can be changed to
n = f->sizelineinfo;
(Disclaimer: untested)
A more complicated option would be to modify the Lua runtime to output the virtual machine program counter instead of the line number, and also output information describing the location of the current function in the chunk (e.g. top level, first function, second function nested in third function, etc). Then the line number could be looked up by the developer in a non-stripped version of the chunk. (Here is a reference to someone using this approach on lua-l -- no source code was provided, though.)
Note that preventing decompilation is not true security. It may help against casual attacks, but Lua bytecode is not hard to read.
luac does not encrypt the output. It compiles your Lua source code to bytecode, that's all. The code is neither encrypted nor does it run any faster, only the loadtime is shorter since the compilation step is not needed.
If you want your code to be encrypted, I suggest to encrypt the bytecode using e.g. AES-256 and then decode it in memory just before handing it to the Lua state. This way the bytecode is encrypted on disk, but decripted in memory.
The overhead is low. We use this technique since years.
I have a generated report in Informix 4GL that prints to the screen.
I need to have one column displayed in reverse format.
I tried the following:
print line_image attribute(reverse)
But that doesn't work. Is this possible at all?
Adding on to the previous answer, you can try the following
print "\033[7mHello \033[0mWorld"
\033[7m means to print in reverse. And, \033[0m means to go back to standard.
If you mean "is there any way at all to do it", the answer's "yes". If you mean "is there a nice easy built-in way to do it", the answer's "no".
What you'll need to do is:
Determine the character sequence that switches to 'reverse' video — store the characters in a string variable brv (begin reverse video; choose your own name if you don't like mine).
Determine the character sequence that switches to 'normal' video — store the characters in a string variable erv (end reverse video).
Arrange for your printing to use:
PRINT COLUMN 1, first_lot_of_data,
COLUMN 37, brv, reverse_data,
COLUMN 52, erv,
COLUMN 56, next_lot_of_data
There'll probably be 3 or 4 characters needed to switch. Those characters will be counted by the column-counting code in the report.
Different terminal types will have different sequences. These days, the chances are your not dealing with the huge variety of actual green-screen terminals that were prevalent in the mid-80s, so you may be able to hardwire your findings for the brv and erv strings. OTOH, you may have to do some fancy footwork to find the correct sequences for different terminals at runtime. Shout if you need more information on this.
A simple way which might allow you to discover the relevant sequences is to run a program such as (this hasn't been anywhere near an I4GL compiler — there are probably syntax errors in it):
MAIN
DISPLAY "HI" AT 1,1
DISPLAY "REVERSE" AT 1,4 ATTRIBUTE(REVERSE)
DISPLAY "LO" AT 1, 12
SLEEP 2
END MAIN
Compile that into terminfo.4ge and run:
./terminfo.4ge # So you know what the screen looks like
./terminfo.4ge > out.file
There's a chance that won't use the display attributes. You'd see that if you run cat out.file and don't see the reverse flash up, then we have to work harder.
You could also look at the terminal entry in the termcap file or from the terminfo entry. Use infocmp $TERM (with the correct terminal type set in the environment variable) and look for the smso (enter standout mode) and rmso (exit standout mode) capabilities. Decipher those (I have rmso=\E[27m and smso=\E[7m for an xterm-256color terminal; the \E is ASCII ESC or \033) and use them in the brv and erv strings. Note that rmso is 5 characters long.
It is possible to write HDF5 to stdout and read from stdin (via H5::File file("/dev/stdout",H5F_ACC_RDONLY) or otherwise)?
What I want is to have a program foo to write to an HDF5 file (taken to be its first argument, say) and another program bar to read from an HDF5 file and then instead of
command_prompt> foo temp.h5
command_prompt> bar temp.h5
command_prompt> rm temp.h5
simply say
command_prompt> foo - | bar -
where the programs foo and bar understand the special file name - to mean stdout and stdin respectively. In order to write those programs, I want to know 1) whether this is at all possible and 2) how I implement this, i.e. what to pass to H5Fcreate() and H5Fopen(), respectively, in case file name = -.
I tried and it seems impossible (not a big surprise). HDF5 only has H5Fcreate(), H5Fopen(), and H5Freopen(), neither of which seems to support I/O to stdin/stdout.
I do not think you can use stdin as an hdf5 input file. The library needs to seek around between the header contents and the data, and you cannot do that with stdin.
i have some shell scripts those printing some message to stdout, and i want to spawn some other process if output matches some regexp, i may also want to hang the shell for a while untill the other process give some feed back. my requirement basically behaves like pipe in shell and tcl expect, or pexpect in python, and my question is, does lua provide such feature?
i've considered a little lua's coroutine but it cannot yield during the middle of executing a shell script, so i did not dig.
Sadly, Lua doesn't provide piping support out of the box, so you'll have to choose between reading and writing. The closest you can get is by iterating through the :lines() of a io.popen()ed process:
for line in io.popen('/some/other/process'):lines() do
-- previous line will block until output is available
if line:match '^some regex' then
-- match found! do some stuff
end
end -- EOF reached
If you have access to C modules, luaposix provides an interface to pipe() throughposix.pipe()
However, bear in mind Lua may not be the most appropriate tool for the job. IMHO you'll be better off using TCL or Python, or even a bash script.
Are there any conventions for formatting console output from a command line app for readability and consistency? For instance, do you indent sub-information, when do you print a blank line, if ever, how should you accent important statements.
I've found output can quickly degenerate into a chaotic blur. I'm interested in hearing about what other people do.
Update: Really this is for embedded software which spits debug status out a terminal, but it's pretty much like a console app, and I figured everyone would be more familiar with that. Thanks so far.
I'd differentiate two kinds of programs:
Do you print information that might be used by a script (i.e. it should be parseable)? Then define a pretty strict format and use only that (for example fixed field separators).
Do you print information that need not be parsed by a script (or is there an alternative script-parseable format already)? Then write what comes natural:
My suggestions:
write it so that you would like to read it
indent sub-information 2 or 4 spaces, definitely not more
separate blocks of information by one empty line at most
respect the COLUMN environment variable (and possible ROWS if it applies to your output).
If this is for a *nix environment, then I'd recommend reading Basics of Unix Philosophy. It's not specific to output but there are some good guidelines for command line programs in general.
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.