Reputation
3,090
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
5 25
Newest
 Custodian
Impact
~61k people reached

5h
awarded  Custodian
5h
reviewed Close Linux debian based new distro development
5h
comment Linux debian based new distro development
If you want to build a small Linux, you should probably not start with Kali — it's a space hog.
5h
awarded  Custodian
5h
reviewed Leave Closed Which filesystem information are considered to be userspace relevant?
5h
comment Which filesystem information are considered to be userspace relevant?
I'm unclear what you're asking (TMI-TL;DR), but it occurs to me that file sparseness could be directly relevant in user space.  Also, overall filesystem layout (i.e., defragmentation) may result in performance benefits that are detectable at the user level.
14h
awarded  Custodian
1d
answered How to add a header and/or footer to a sed or awk stream?
1d
comment Optimize/Replace 'find' command
No, on Unix & Linux, a newline is one byte.  The reason to use -print0 and -0 is that filenames can contain newlines, so a line-by-line list of filenames is inherently ambiguous.  Filenames cannot contain NULLs, so a NULL-separated list of filenames is unambiguous, even in the presence of filenames containing newlines.
1d
comment Optimize/Replace 'find' command
@Dalvenjia, heemayl: I don't think so.  I'm pretty sure that find … -exec … + will do as many execs as it needs to stay within the relevant limits.  And, BTW, unless you do -exec sh -c "…" +, the shell has nothing to do with it — find executes the requested program (e.g., mv) directly.
1d
comment What does 'exec {fd}</dev/watchdog' do in Bash
@chepner: Thanks.  D’oh!  Hidden in plain sight.  I’ve been eating Unix man pages for breakfast for a longer time than I choose to admit, and I still occasionally choke on one.  It sometimes seems as though the authors were writing for some target demographic other than human beings.  P.S. I can’t find it in POSIX, so it may be available only in bash.
1d
comment What does 'exec {fd}</dev/watchdog' do in Bash
I'm sure that you're right, because (1) I recall reading it somewhere, and (2) I just tried it (and it works).  But I couldn't find it documented anywhere.  (Of course, I had less than ten minutes to search before you posted your answer.)  Can you provide a reference to where it is documented?
1d
comment Need output in a good format using shell script
(Cont’d)  … (2) The original version of the question had blank lines probably because the OP didn’t know how else to get line breaks; it’s unclear whether they ever were present in his data.
1d
comment Need output in a good format using shell script
(1) Of course you don’t need the terminal semicolon and the separating spaces if you use parentheses: (head -n 1; something else).  As I’m sure you two (jimmij and Peter.O) know, (command(s)) is functionally equivalent to { command(s); } if the command(s) don’t alter the shell’s state (cd, set variables, etc.).  I believe that the (…) version spawns an extra process, which is resource-wasteful in a trivial way, but I seem to recall hearing otherwise (“the shell needs to fork to run the command(s) either way”).  … (Cont’d)
1d
revised How to pass an argument to a java process from within a shell script
Fixed typos.
1d
comment Job control over a Bash script
Also, you should warn the user to disable the SIGINT → exit trap immediately upon termination of the script; otherwise, the next time he types (Ctrl)+(C) at a shell prompt (i.e., when he doesn't have a command running in the foreground), the shell will exit.
1d
comment Job control over a Bash script
OK, I know that -- insulates you against the possibility that the next word might begin with -, but is there any reason to use it when you know what the next word is, and it does not begin with -?
2d
comment Job control over a Bash script
By the way, we Unix & Linux people don't use the phrase "batch file".
2d
comment Running a C++ compiled program in the background and sending input whenever needed
When everything is tested and integrated, the final command line for the system will be something like their_program | your_program &.  Since the pipe (from their program) is now the standard input (stdin) to your program, the code you have now to read from std::cin should work, unchanged.  Test with your_testscript | your_program &, where your test script does things like sleep 600, echo "The quick brown fox ...", sleep 420, echo "jumps over the lazy dog.", ...
2d
comment Running a C++ compiled program in the background and sending input whenever needed
Well, I still don't understand.  If the other developers suggested that you modify your program to be able to handle text input, and they promised to adjust their code to synchronize with yours, does that mean that, when everything is integrated, their program will be piped into yours?  If so, then you should test your program with input coming from a pipe.