07-15-2009
When a process that is on the left side of the pipe writes some output and the process on the right has exited, the SIGPIPE signal is passed to the left process. If it is not handled, the default shell behaviour is to terminate that process.
It seems that the echo builtin doesn't handle SIGPIPE signal, whereas /bin/echo ignores it.
10 More Discussions You Might Find Interesting
1. Shell Programming and Scripting
hi guys
wht is the difference between these two command in bash shell scripting
$var1=world!
$echo hello $var1
$echo "hello $var1" (8 Replies)
Discussion started by: srinivas2828
8 Replies
2. Shell Programming and Scripting
Hi,
I've modified the syslogd source to include a thread that will keep track of a timer(or a timer thread). My intention is to check the file size of /var/log/messages in every one minute & if the size is more than 128KB, do a echo " " > /var/log/messages, so that the file size will be set... (7 Replies)
Discussion started by: jockey007
7 Replies
3. Shell Programming and Scripting
Hello All
Nice to meet you all here in this forum,
it's my 1rst time here
i'm asking about a little issue that i face
i added a ksh script that echo " please insert your name " and store the output to a login.log file.
the script is working fine with normal telnet
but Xstart is not working... (8 Replies)
Discussion started by: islam.said
8 Replies
4. Shell Programming and Scripting
echo `echo ` doesn't echoes anything. And it's logic. But
echo `echo `echo ` ` does echoes "echo". What's the logic of it? the `echo `echo ` inside of the whole (first) echo, echoes nothing, so the first echo have to echo nothing but echoes "echo"
(too much echoing :P):o (2 Replies)
Discussion started by: hakermania
2 Replies
5. UNIX for Dummies Questions & Answers
what if the difference between
#!/bin/sh
and
#!/bin/bash
I wrote a script with the second heading now when i change my heading to the first one ...the script is not executing well....im not getting the required output....any solution to this problem...or do i have to start the... (3 Replies)
Discussion started by: xerox
3 Replies
6. Shell Programming and Scripting
Hi guys,
I have a shell script where I have the following:
for i in ad0 ad1
do
gpart create -s gpt $i || echo "Cannot create GPT partition on "$i". Exiting ..."
gpart add -s 128 -t freebsd-boot $i || echo "Cannot add freebsd-boot partition on "$i". Exiting ..."
gpart add -s 4G -t... (2 Replies)
Discussion started by: da1
2 Replies
7. AIX
Hi Folks,
As per the subject, the following command is not working as expected.
echo $variable | mail -s "subject" "xxx@xxx.com"
Could anyone figure it out whats wrong with this. I am using AIX box.
Regards, (2 Replies)
Discussion started by: gjarms
2 Replies
8. Shell Programming and Scripting
I came across and unexpected behavior with redirections in tcsh. I know, csh is not best for redirections, but I'd like to understand what is happening here.
I have following script (called out_to_streams.csh):
#!/bin/tcsh -f
echo Redirected to STDOUT > /dev/stdout
echo Redirected to... (2 Replies)
Discussion started by: marcink
2 Replies
9. UNIX for Dummies Questions & Answers
Hi guys,
Been messing around with shell programming for a couple of days and I found something that was pretty odd in the behavior of the echo command. Below is an example-:
When I type the following in my /home directory from my lxterminal in Debian-:
echo "`ls -l`"
I get the... (2 Replies)
Discussion started by: sreyan32
2 Replies
10. Shell Programming and Scripting
I'm on Ubuntu 14.04 and I manually updated my coreutils so that "tee" is now on version 8.27
I was running a script using bash where there is some write to pipe error at some point causing the tee command to exit abruptly while the script continues to run. The newer version of tee seems to prevent... (2 Replies)
Discussion started by: stompadon
2 Replies
LEARN ABOUT DEBIAN
io_trywrite
io_trywrite(3) Library Functions Manual io_trywrite(3)
NAME
io_trywrite - write to a descriptor without blocking
SYNTAX
#include <io.h>
int io_trywrite(int64 fd,const char* buf,int64 len);
DESCRIPTION
io_trywrite tries to write len bytes of data from buf[0], buf[1], ..., buf[len-1] to descriptor fd. (The effects are undefined if len is 0
or smaller.) There are several possible results:
o o_trywrite returns an integer between 1 and len: This number of bytes was immediately written from the beginning of buf. Note that this
number can be, and often is, smaller than len; you must not assume that io_trywrite always succeeds in writing exactly len bytes.
o io_trywrite returns -1, setting errno to EAGAIN: No bytes were written, because the descriptor is not ready. For example, the descriptor
is writing to a full pipe that could still be read.
o io_trywrite returns -3, setting errno to something other than EAGAIN: No bytes were written, because the write attempt encountered a
persistent error, such as a serious disk failure (EIO), an unreachable network (ENETUNREACH), or an invalid descriptor number (EBADF).
io_trywrite does not pause waiting for a descriptor that is not ready. If you want to pause, use io_waitread or io_wait.
You can make io_trywrite faster and more efficient by making the socket non-blocking with io_nonblock().
Once upon a time, many UNIX programs neglected to check the success of their writes. They would often encounter EPIPE, and would blithely
continue writing, rather than exiting with an appropriate exit code. The UNIX kernel developers decided to send a SIGPIPE signal, which
terminates the process by default, along with returning EPIPE. This papers over the problem without fixing it: the same programs ignore
other errors such as EIO. One hopes that the programs have been fixed by now; kernels nevertheless continue to generate the SIGPIPE signal.
The first time io_trywrite or io_waitwrite is called, it arranges for SIGPIPE to be ignored. (Technically, for SIGPIPE to be caught by an
empty signal handler, so this doesn't affect child processes.) Do not use SIGPIPE elsewhere in the program.
SEE ALSO
io_nonblock(3), io_waitread(3), io_trywritetimeout(3)
io_trywrite(3)