STDOUT + STDERR output … is there any difference between considering the output to be an empty string vs...
up vote
0
down vote
favorite
I'm writing some application code that is used to execute Linux shell commands, and it then logs the command details into an SQL database. This includes the output of STDOUT + STDERR (separately).
After the command has been executed, and assuming the process didn't output anything... could there be any reason to leave the STDOUT/STDERR fields as NULL -vs- setting them to be empty strings?
To put the question another way: is there technically any difference between these two things?
- A process that doesn't output anything to STDOUT
- A process that outputs an empty string to STDOUT (and nothing else)
And to put the question another way again... does it make sense to make these columns NOT NULL in SQL?
process pipe stdout file-descriptors stderr
add a comment |
up vote
0
down vote
favorite
I'm writing some application code that is used to execute Linux shell commands, and it then logs the command details into an SQL database. This includes the output of STDOUT + STDERR (separately).
After the command has been executed, and assuming the process didn't output anything... could there be any reason to leave the STDOUT/STDERR fields as NULL -vs- setting them to be empty strings?
To put the question another way: is there technically any difference between these two things?
- A process that doesn't output anything to STDOUT
- A process that outputs an empty string to STDOUT (and nothing else)
And to put the question another way again... does it make sense to make these columns NOT NULL in SQL?
process pipe stdout file-descriptors stderr
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm writing some application code that is used to execute Linux shell commands, and it then logs the command details into an SQL database. This includes the output of STDOUT + STDERR (separately).
After the command has been executed, and assuming the process didn't output anything... could there be any reason to leave the STDOUT/STDERR fields as NULL -vs- setting them to be empty strings?
To put the question another way: is there technically any difference between these two things?
- A process that doesn't output anything to STDOUT
- A process that outputs an empty string to STDOUT (and nothing else)
And to put the question another way again... does it make sense to make these columns NOT NULL in SQL?
process pipe stdout file-descriptors stderr
I'm writing some application code that is used to execute Linux shell commands, and it then logs the command details into an SQL database. This includes the output of STDOUT + STDERR (separately).
After the command has been executed, and assuming the process didn't output anything... could there be any reason to leave the STDOUT/STDERR fields as NULL -vs- setting them to be empty strings?
To put the question another way: is there technically any difference between these two things?
- A process that doesn't output anything to STDOUT
- A process that outputs an empty string to STDOUT (and nothing else)
And to put the question another way again... does it make sense to make these columns NOT NULL in SQL?
process pipe stdout file-descriptors stderr
process pipe stdout file-descriptors stderr
asked Dec 6 at 3:02
LaVache
17839
17839
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
In a pipe (std-err/out) there is no concept of an empty string, it's just "no output";
> printf ''
> printf '' | xxd
where as null is something
> printf ''
> printf '' | xxd
00000000: 00
The opposite is true in a database, and less is more, so have your scripts silent(empty string) and your DB empty(null).
add a comment |
up vote
0
down vote
Not sure I understand the question, but:
Writing to stdout is performing a:
write(1, memory_address, length)
Which writes length bytes stored at the memory_address to file descriptor 1 (1 for stdout, 2 for stderr). For instance, in echo test, echo (or the shell if echo is builtin) performs a write(1, "testn", 5).
Though, it's a bit silly, you can call the write() system call with a length of 0.
With:
write(1, address, 0)
At least on Linux, the system call still checks that the file descriptor has been open in write or read+write mode, and that the address is a valid address (though it doesn't have to be readable). If stdout is a broken pipe, I don't see it causing a SIGPIPE signal delivery though.
So doing that of size zero is not strictly equivalent to not doing any write at all in that it could cause errors.
In practice, I find that most commands avoid the write() if they can.
I find that echo -n and printf '' don't do any write() system call in all the implementations I've tried. stdio functions (fputs()/printf()/fwrite()... don't perform any write() when you ask them to write an empty string).
To perform a 0-length write, you can try:
perl -e 'syswrite(STDOUT, "")'
Or
python -c 'import os; os.write(1, "")'
Which are raw interfaces in those interpreters to write().
Example:
$ strace -e write /bin/echo -n
$ strace -e write python -c 'import os; os.write(1, "")'
write(1, "", 0) = 0
$ python -c 'import os; os.write(1, "")' >&-
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ python -c 'import os; os.write(1, "")' 1< /dev/null
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)-1,0);}' | strace -e write tcc -run -
write(1, "", 0) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,1);}' | strace -e write tcc -run -
write(1, NULL, 1) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,0);}' | strace -e write tcc -run -
write(1, NULL, 0) = 0
A write with length 0 is not silly if the fd is a datagram or seqpacket socket; it will send a packet of size 0 which could be used to signal an EOF, for instance (if you create 2 datagram sockets with socketpair(), closing one of them will not result in a read f length 0 (eof) on the other. IIRC)
– mosvy
Dec 6 at 14:08
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f486280%2fstdout-stderr-output-is-there-any-difference-between-considering-the-outpu%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
In a pipe (std-err/out) there is no concept of an empty string, it's just "no output";
> printf ''
> printf '' | xxd
where as null is something
> printf ''
> printf '' | xxd
00000000: 00
The opposite is true in a database, and less is more, so have your scripts silent(empty string) and your DB empty(null).
add a comment |
up vote
1
down vote
In a pipe (std-err/out) there is no concept of an empty string, it's just "no output";
> printf ''
> printf '' | xxd
where as null is something
> printf ''
> printf '' | xxd
00000000: 00
The opposite is true in a database, and less is more, so have your scripts silent(empty string) and your DB empty(null).
add a comment |
up vote
1
down vote
up vote
1
down vote
In a pipe (std-err/out) there is no concept of an empty string, it's just "no output";
> printf ''
> printf '' | xxd
where as null is something
> printf ''
> printf '' | xxd
00000000: 00
The opposite is true in a database, and less is more, so have your scripts silent(empty string) and your DB empty(null).
In a pipe (std-err/out) there is no concept of an empty string, it's just "no output";
> printf ''
> printf '' | xxd
where as null is something
> printf ''
> printf '' | xxd
00000000: 00
The opposite is true in a database, and less is more, so have your scripts silent(empty string) and your DB empty(null).
edited Dec 6 at 13:03
answered Dec 6 at 3:35
user1133275
2,808519
2,808519
add a comment |
add a comment |
up vote
0
down vote
Not sure I understand the question, but:
Writing to stdout is performing a:
write(1, memory_address, length)
Which writes length bytes stored at the memory_address to file descriptor 1 (1 for stdout, 2 for stderr). For instance, in echo test, echo (or the shell if echo is builtin) performs a write(1, "testn", 5).
Though, it's a bit silly, you can call the write() system call with a length of 0.
With:
write(1, address, 0)
At least on Linux, the system call still checks that the file descriptor has been open in write or read+write mode, and that the address is a valid address (though it doesn't have to be readable). If stdout is a broken pipe, I don't see it causing a SIGPIPE signal delivery though.
So doing that of size zero is not strictly equivalent to not doing any write at all in that it could cause errors.
In practice, I find that most commands avoid the write() if they can.
I find that echo -n and printf '' don't do any write() system call in all the implementations I've tried. stdio functions (fputs()/printf()/fwrite()... don't perform any write() when you ask them to write an empty string).
To perform a 0-length write, you can try:
perl -e 'syswrite(STDOUT, "")'
Or
python -c 'import os; os.write(1, "")'
Which are raw interfaces in those interpreters to write().
Example:
$ strace -e write /bin/echo -n
$ strace -e write python -c 'import os; os.write(1, "")'
write(1, "", 0) = 0
$ python -c 'import os; os.write(1, "")' >&-
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ python -c 'import os; os.write(1, "")' 1< /dev/null
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)-1,0);}' | strace -e write tcc -run -
write(1, "", 0) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,1);}' | strace -e write tcc -run -
write(1, NULL, 1) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,0);}' | strace -e write tcc -run -
write(1, NULL, 0) = 0
A write with length 0 is not silly if the fd is a datagram or seqpacket socket; it will send a packet of size 0 which could be used to signal an EOF, for instance (if you create 2 datagram sockets with socketpair(), closing one of them will not result in a read f length 0 (eof) on the other. IIRC)
– mosvy
Dec 6 at 14:08
add a comment |
up vote
0
down vote
Not sure I understand the question, but:
Writing to stdout is performing a:
write(1, memory_address, length)
Which writes length bytes stored at the memory_address to file descriptor 1 (1 for stdout, 2 for stderr). For instance, in echo test, echo (or the shell if echo is builtin) performs a write(1, "testn", 5).
Though, it's a bit silly, you can call the write() system call with a length of 0.
With:
write(1, address, 0)
At least on Linux, the system call still checks that the file descriptor has been open in write or read+write mode, and that the address is a valid address (though it doesn't have to be readable). If stdout is a broken pipe, I don't see it causing a SIGPIPE signal delivery though.
So doing that of size zero is not strictly equivalent to not doing any write at all in that it could cause errors.
In practice, I find that most commands avoid the write() if they can.
I find that echo -n and printf '' don't do any write() system call in all the implementations I've tried. stdio functions (fputs()/printf()/fwrite()... don't perform any write() when you ask them to write an empty string).
To perform a 0-length write, you can try:
perl -e 'syswrite(STDOUT, "")'
Or
python -c 'import os; os.write(1, "")'
Which are raw interfaces in those interpreters to write().
Example:
$ strace -e write /bin/echo -n
$ strace -e write python -c 'import os; os.write(1, "")'
write(1, "", 0) = 0
$ python -c 'import os; os.write(1, "")' >&-
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ python -c 'import os; os.write(1, "")' 1< /dev/null
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)-1,0);}' | strace -e write tcc -run -
write(1, "", 0) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,1);}' | strace -e write tcc -run -
write(1, NULL, 1) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,0);}' | strace -e write tcc -run -
write(1, NULL, 0) = 0
A write with length 0 is not silly if the fd is a datagram or seqpacket socket; it will send a packet of size 0 which could be used to signal an EOF, for instance (if you create 2 datagram sockets with socketpair(), closing one of them will not result in a read f length 0 (eof) on the other. IIRC)
– mosvy
Dec 6 at 14:08
add a comment |
up vote
0
down vote
up vote
0
down vote
Not sure I understand the question, but:
Writing to stdout is performing a:
write(1, memory_address, length)
Which writes length bytes stored at the memory_address to file descriptor 1 (1 for stdout, 2 for stderr). For instance, in echo test, echo (or the shell if echo is builtin) performs a write(1, "testn", 5).
Though, it's a bit silly, you can call the write() system call with a length of 0.
With:
write(1, address, 0)
At least on Linux, the system call still checks that the file descriptor has been open in write or read+write mode, and that the address is a valid address (though it doesn't have to be readable). If stdout is a broken pipe, I don't see it causing a SIGPIPE signal delivery though.
So doing that of size zero is not strictly equivalent to not doing any write at all in that it could cause errors.
In practice, I find that most commands avoid the write() if they can.
I find that echo -n and printf '' don't do any write() system call in all the implementations I've tried. stdio functions (fputs()/printf()/fwrite()... don't perform any write() when you ask them to write an empty string).
To perform a 0-length write, you can try:
perl -e 'syswrite(STDOUT, "")'
Or
python -c 'import os; os.write(1, "")'
Which are raw interfaces in those interpreters to write().
Example:
$ strace -e write /bin/echo -n
$ strace -e write python -c 'import os; os.write(1, "")'
write(1, "", 0) = 0
$ python -c 'import os; os.write(1, "")' >&-
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ python -c 'import os; os.write(1, "")' 1< /dev/null
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)-1,0);}' | strace -e write tcc -run -
write(1, "", 0) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,1);}' | strace -e write tcc -run -
write(1, NULL, 1) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,0);}' | strace -e write tcc -run -
write(1, NULL, 0) = 0
Not sure I understand the question, but:
Writing to stdout is performing a:
write(1, memory_address, length)
Which writes length bytes stored at the memory_address to file descriptor 1 (1 for stdout, 2 for stderr). For instance, in echo test, echo (or the shell if echo is builtin) performs a write(1, "testn", 5).
Though, it's a bit silly, you can call the write() system call with a length of 0.
With:
write(1, address, 0)
At least on Linux, the system call still checks that the file descriptor has been open in write or read+write mode, and that the address is a valid address (though it doesn't have to be readable). If stdout is a broken pipe, I don't see it causing a SIGPIPE signal delivery though.
So doing that of size zero is not strictly equivalent to not doing any write at all in that it could cause errors.
In practice, I find that most commands avoid the write() if they can.
I find that echo -n and printf '' don't do any write() system call in all the implementations I've tried. stdio functions (fputs()/printf()/fwrite()... don't perform any write() when you ask them to write an empty string).
To perform a 0-length write, you can try:
perl -e 'syswrite(STDOUT, "")'
Or
python -c 'import os; os.write(1, "")'
Which are raw interfaces in those interpreters to write().
Example:
$ strace -e write /bin/echo -n
$ strace -e write python -c 'import os; os.write(1, "")'
write(1, "", 0) = 0
$ python -c 'import os; os.write(1, "")' >&-
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ python -c 'import os; os.write(1, "")' 1< /dev/null
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)-1,0);}' | strace -e write tcc -run -
write(1, "", 0) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,1);}' | strace -e write tcc -run -
write(1, NULL, 1) = -1 EFAULT (Bad address)
$ printf '%sn' '#include <unistd.h>' 'main(){write(1,(char*)0,0);}' | strace -e write tcc -run -
write(1, NULL, 0) = 0
edited Dec 6 at 13:45
answered Dec 6 at 13:39
Stéphane Chazelas
298k54562909
298k54562909
A write with length 0 is not silly if the fd is a datagram or seqpacket socket; it will send a packet of size 0 which could be used to signal an EOF, for instance (if you create 2 datagram sockets with socketpair(), closing one of them will not result in a read f length 0 (eof) on the other. IIRC)
– mosvy
Dec 6 at 14:08
add a comment |
A write with length 0 is not silly if the fd is a datagram or seqpacket socket; it will send a packet of size 0 which could be used to signal an EOF, for instance (if you create 2 datagram sockets with socketpair(), closing one of them will not result in a read f length 0 (eof) on the other. IIRC)
– mosvy
Dec 6 at 14:08
A write with length 0 is not silly if the fd is a datagram or seqpacket socket; it will send a packet of size 0 which could be used to signal an EOF, for instance (if you create 2 datagram sockets with socketpair(), closing one of them will not result in a read f length 0 (eof) on the other. IIRC)
– mosvy
Dec 6 at 14:08
A write with length 0 is not silly if the fd is a datagram or seqpacket socket; it will send a packet of size 0 which could be used to signal an EOF, for instance (if you create 2 datagram sockets with socketpair(), closing one of them will not result in a read f length 0 (eof) on the other. IIRC)
– mosvy
Dec 6 at 14:08
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f486280%2fstdout-stderr-output-is-there-any-difference-between-considering-the-outpu%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown