thr3ads.net - dtrace discuss - [dtrace-discuss] trace("") prints hex dump table [Feb 2006]

If this information is useful, please help other people find it:
Share via:

William D. Hathaway

2006-Feb-25 18:04 UTC

[dtrace-discuss] trace("") prints hex dump table

I''m running
SunOS unknown 5.11 snv_33 i86pc i386 i86pc

and to print a blank line in the output of my script I tried adding:

trace("");

which printed
             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef
         0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

It doesn''t seem like that is expected behavior. Is this a known bug?
This message posted from opensolaris.org

Michael Shapiro

2006-Feb-26 21:13 UTC

head link

[dtrace-discuss] trace("") prints hex dump table

> 
> I''m running
> SunOS unknown 5.11 snv_33 i86pc i386 i86pc
> 
> and to print a blank line in the output of my script I tried adding:
> 
> trace("");
> 
> which printed
>              0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 
0123456789abcdef
>          0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
> 
> It doesn''t seem like that is expected behavior. Is this a known
bug?
This is RFE:

6205017 default string formatting heuristic should identify empty strings

At present, trace() uses some simple heuristics to decide how to print
the data as either an integer, string, or blob of raw data.  In the case
of something that is large and all zeroes, we''re defaulting to raw data
output.
So you get the above output if you trace a string or a zero-filled struct, say.

We can make this smarter, as per the RFE, but if your intent is to product
a blank line of output in a script emitting text you should be using:

	printf("\n");

instead.  trace() will always be heuristic; printf() is for when you want
to programmatically and precisely control the output.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

CHIAN-PHON LIN

2006-Feb-27 22:16 UTC

head link

[dtrace-discuss] ftruncate() truncates standard error?

Hi,

I know that ftruncate() truncates standard output file.
Does it also truncate standard error file?  If not, what is
the syntax for truncating standard error file.

THX.
-- 
************************************************
* C P Lin, Common Technology Project Lead.     *
* Sun Microsystems Inc.                        *
* E-Mail:  c.lin at sun.com                       *
* Address: 4150 Network Circle, M/S UMPK12-330 *
* Santa Clara, CA 95054                        *
* Phone:   650/352-4967	   Fax: 650/786-7816   *
************************************************

Jonathan Adams

2006-Feb-27 22:28 UTC

head link

[dtrace-discuss] ftruncate() truncates standard error?

On Mon, Feb 27, 2006 at 02:16:59PM -0800, CHIAN-PHON LIN
wrote:> Hi,
> 
> I know that ftruncate() truncates standard output file.
> Does it also truncate standard error file?
No.
>  If not, what is
> the syntax for truncating standard error file.
You have to re-open stdout as stderr, truncate, then re-open the original
stdout.  i.e.:

# cat > script.d <<EOF
#!/usr/sbin/dtrace -s

#pragma D option quiet
#pragma D option destructive

BEGIN
{
	printf("data\n");
	freopen("/dev/stderr");
	ftruncate();
	freopen("");	/* re-open original stdout */
	printf("more data\n");
	exit(0);
}
EOF
# chmod a+x script.d
# echo foo > stdout
# echo foofoo > stderr
# ls -l std*
-rw-r--r--   1 root     root           7 Feb 27 14:21 stderr
-rw-r--r--   1 root     root           4 Feb 27 14:21 stdout
# ./script.d >>stdout 2>>stderr
# ls -l std*
-rw-r--r--   1 root     root           0 Feb 27 14:26 stderr
-rw-r--r--   1 root     root          19 Feb 27 14:26 stdout
# cat stdout
foo
data
more data
#

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

Adam Zhang

2006-Feb-28 02:31 UTC

head link

[dtrace-discuss] ftruncate() truncates standard error?

Hi Jonathan,

I run the script you write on x86, but it looks it doesn''t work.

-bash-3.00# ./script.d >>stdout 2>>stderr
-bash-3.00# ls -l std*
-rw-r--r--   1 root     root           7 Feb 28 10:26 stderr
-rw-r--r--   1 root     root          36 Feb 28 10:28 stdout
-bash-3.00# more script.d
#!/usr/sbin/dtrace -s

#pragma D option quiet
#pragma D option destructive
BEGIN
{
printf("data\n");
freopen("/dev/stderr");
ftruncate();
freopen("");/* re-open original stdout */
printf("more data\n");
exit(0);
}

Regards,
Adam Zhang

Jonathan Adams wrote:> On Mon, Feb 27, 2006 at 02:16:59PM -0800, CHIAN-PHON LIN wrote:
>   
>> Hi,
>>
>> I know that ftruncate() truncates standard output file.
>> Does it also truncate standard error file?
>>     
>
> No.
>
>   
>>  If not, what is
>> the syntax for truncating standard error file.
>>     
>
> You have to re-open stdout as stderr, truncate, then re-open the original
> stdout.  i.e.:
>
> # cat > script.d <<EOF
> #!/usr/sbin/dtrace -s
>
> #pragma D option quiet
> #pragma D option destructive
>
> BEGIN
> {
> 	printf("data\n");
> 	freopen("/dev/stderr");
> 	ftruncate();
> 	freopen("");	/* re-open original stdout */
> 	printf("more data\n");
> 	exit(0);
> }
> EOF
> # chmod a+x script.d
> # echo foo > stdout
> # echo foofoo > stderr
> # ls -l std*
> -rw-r--r--   1 root     root           7 Feb 27 14:21 stderr
> -rw-r--r--   1 root     root           4 Feb 27 14:21 stdout
> # ./script.d >>stdout 2>>stderr
> # ls -l std*
> -rw-r--r--   1 root     root           0 Feb 27 14:26 stderr
> -rw-r--r--   1 root     root          19 Feb 27 14:26 stdout
> # cat stdout
> foo
> data
> more data
> #
>
> Cheers,
> - jonathan
>
>

Jonathan Adams

2006-Feb-28 03:51 UTC

head link

[dtrace-discuss] ftruncate() truncates standard error?

On Tue, Feb 28, 2006 at 10:31:17AM +0800, Adam Zhang
wrote:> Hi Jonathan,
> 
> I run the script you write on x86, but it looks it doesn''t work.
> 
> -bash-3.00# ./script.d >>stdout 2>>stderr
> -bash-3.00# ls -l std*
> -rw-r--r--   1 root     root           7 Feb 28 10:26 stderr
> -rw-r--r--   1 root     root          36 Feb 28 10:28 stdout
> -bash-3.00# more script.d
> #!/usr/sbin/dtrace -s
> 
> #pragma D option quiet
> #pragma D option destructive
> BEGIN
> {
> printf("data\n");
> freopen("/dev/stderr");
> ftruncate();
> freopen("");/* re-open original stdout */
> printf("more data\n");
> exit(0);
> }
It works on my x86 box, running snv_33;  what is the contents of stderr and
stdout, and what is the output of "uname -a"?

Cheers,
- jonathan
> Regards,
> Adam Zhang
> 
> Jonathan Adams wrote:
> >On Mon, Feb 27, 2006 at 02:16:59PM -0800, CHIAN-PHON LIN wrote:
> >  
> >>Hi,
> >>
> >>I know that ftruncate() truncates standard output file.
> >>Does it also truncate standard error file?
> >>    
> >
> >No.
> >
> >  
> >> If not, what is
> >>the syntax for truncating standard error file.
> >>    
> >
> >You have to re-open stdout as stderr, truncate, then re-open the
original
> >stdout.  i.e.:
> >
> ># cat > script.d <<EOF
> >#!/usr/sbin/dtrace -s
> >
> >#pragma D option quiet
> >#pragma D option destructive
> >
> >BEGIN
> >{
> >	printf("data\n");
> >	freopen("/dev/stderr");
> >	ftruncate();
> >	freopen("");	/* re-open original stdout */
> >	printf("more data\n");
> >	exit(0);
> >}
> >EOF
> ># chmod a+x script.d
> ># echo foo > stdout
> ># echo foofoo > stderr
> ># ls -l std*
> >-rw-r--r--   1 root     root           7 Feb 27 14:21 stderr
> >-rw-r--r--   1 root     root           4 Feb 27 14:21 stdout
> ># ./script.d >>stdout 2>>stderr
> ># ls -l std*
> >-rw-r--r--   1 root     root           0 Feb 27 14:26 stderr
> >-rw-r--r--   1 root     root          19 Feb 27 14:26 stdout
> ># cat stdout
> >foo
> >data
> >more data
> >#
> >
> >Cheers,
> >- jonathan
> >
> >  
-- 
Jonathan Adams, Solaris Kernel Development

Adam Zhang

2006-Feb-28 03:57 UTC

head link

[dtrace-discuss] ftruncate() truncates standard error?

Hi Jonathan,

The output of ''uname -a'' is:
SunOS florida 5.10 Generic_118844-28 i86pc i386 i86pc

The contents of stderr and stdout file are:
-bash-3.00# more stderr
foofoo
-bash-3.00# more stdout
foo
data
more data

-bash-3.00#

This machine is on the SWAN. I will send you the password separately. 
Thank you in advance!

Regards,
Adam

Jonathan Adams wrote:> On Tue, Feb 28, 2006 at 10:31:17AM +0800, Adam Zhang wrote:
>   
>> Hi Jonathan,
>>
>> I run the script you write on x86, but it looks it doesn''t
work.
>>
>> -bash-3.00# ./script.d >>stdout 2>>stderr
>> -bash-3.00# ls -l std*
>> -rw-r--r--   1 root     root           7 Feb 28 10:26 stderr
>> -rw-r--r--   1 root     root          36 Feb 28 10:28 stdout
>> -bash-3.00# more script.d
>> #!/usr/sbin/dtrace -s
>>
>> #pragma D option quiet
>> #pragma D option destructive
>> BEGIN
>> {
>> printf("data\n");
>> freopen("/dev/stderr");
>> ftruncate();
>> freopen("");/* re-open original stdout */
>> printf("more data\n");
>> exit(0);
>> }
>>     
>
> It works on my x86 box, running snv_33;  what is the contents of stderr and
> stdout, and what is the output of "uname -a"?
>
> Cheers,
> - jonathan
>
>   
>> Regards,
>> Adam Zhang
>>
>> Jonathan Adams wrote:
>>     
>>> On Mon, Feb 27, 2006 at 02:16:59PM -0800, CHIAN-PHON LIN wrote:
>>>  
>>>       
>>>> Hi,
>>>>
>>>> I know that ftruncate() truncates standard output file.
>>>> Does it also truncate standard error file?
>>>>    
>>>>         
>>> No.
>>>
>>>  
>>>       
>>>> If not, what is
>>>> the syntax for truncating standard error file.
>>>>    
>>>>         
>>> You have to re-open stdout as stderr, truncate, then re-open the
original
>>> stdout.  i.e.:
>>>
>>> # cat > script.d <<EOF
>>> #!/usr/sbin/dtrace -s
>>>
>>> #pragma D option quiet
>>> #pragma D option destructive
>>>
>>> BEGIN
>>> {
>>> 	printf("data\n");
>>> 	freopen("/dev/stderr");
>>> 	ftruncate();
>>> 	freopen("");	/* re-open original stdout */
>>> 	printf("more data\n");
>>> 	exit(0);
>>> }
>>> EOF
>>> # chmod a+x script.d
>>> # echo foo > stdout
>>> # echo foofoo > stderr
>>> # ls -l std*
>>> -rw-r--r--   1 root     root           7 Feb 27 14:21 stderr
>>> -rw-r--r--   1 root     root           4 Feb 27 14:21 stdout
>>> # ./script.d >>stdout 2>>stderr
>>> # ls -l std*
>>> -rw-r--r--   1 root     root           0 Feb 27 14:26 stderr
>>> -rw-r--r--   1 root     root          19 Feb 27 14:26 stdout
>>> # cat stdout
>>> foo
>>> data
>>> more data
>>> #
>>>
>>> Cheers,
>>> - jonathan
>>>
>>>  
>>>       
>
>

slindes at gmail.com

2006-Feb-28 09:56 UTC

head link

[dtrace-discuss] ftruncate() truncates standard error?

FYI!
> The output of ''uname -a'' is:
> SunOS florida 5.10 Generic_118844-28 i86pc i386 i86pc
It works here, under
> uname -aSunOS solcar 5.10 Generic_118844-26 i86pc i386 i86pc

/stefan

Jonathan Adams

2006-Feb-28 18:52 UTC

head link

[dtrace-discuss] ftruncate() truncates standard error?

On Tue, Feb 28, 2006 at 11:57:15AM +0800, Adam Zhang
wrote:> Hi Jonathan,
> 
> The output of ''uname -a'' is:
> SunOS florida 5.10 Generic_118844-28 i86pc i386 i86pc
> 
> The contents of stderr and stdout file are:
> -bash-3.00# more stderr
> foofoo
> -bash-3.00# more stdout
> foo
> data
> more data
> 
> -bash-3.00#
> 
> This machine is on the SWAN. I will send you the password separately. 
> Thank you in advance!
Wacky;  your machine is missing the /dev/std* symlinks:

# ls -l /dev/std*
-rw-r--r--   1 root     root           0 Feb 28 10:24 /dev/stderr

as opposed to my machine:

# ls -l /dev/std*
lrwxrwxrwx   1 root     root           4 Feb 10 11:22 /dev/stderr -> fd/2
lrwxrwxrwx   1 root     root           4 Feb 10 11:22 /dev/stdin -> fd/0
lrwxrwxrwx   1 root     root           4 Feb 10 11:22 /dev/stdout -> fd/1

If you replace "/dev/stderr" with "/dev/fd/2", the script
will work.

I''m not sure why you''re missing the symlinks, but
I''ve removed the bogus
/dev/stderr on your machine.  Running pkgchk on SUNWcsd (which provides the
symlinks) revealed:

# pkgchk SUNWcsd
ERROR: /dev
    group name <sys> expected <other> actual
ERROR: /dev/stderr
    pathname does not exist
ERROR: /dev/stdin
    pathname does not exist
ERROR: /dev/stdout
    pathname does not exist
...

Cheers,
- jonathan
> 
> Jonathan Adams wrote:
> >On Tue, Feb 28, 2006 at 10:31:17AM +0800, Adam Zhang wrote:
> >  
> >>Hi Jonathan,
> >>
> >>I run the script you write on x86, but it looks it doesn''t
work.
> >>
> >>-bash-3.00# ./script.d >>stdout 2>>stderr
> >>-bash-3.00# ls -l std*
> >>-rw-r--r--   1 root     root           7 Feb 28 10:26 stderr
> >>-rw-r--r--   1 root     root          36 Feb 28 10:28 stdout
> >>-bash-3.00# more script.d
> >>#!/usr/sbin/dtrace -s
> >>
> >>#pragma D option quiet
> >>#pragma D option destructive
> >>BEGIN
> >>{
> >>printf("data\n");
> >>freopen("/dev/stderr");
> >>ftruncate();
> >>freopen("");/* re-open original stdout */
> >>printf("more data\n");
> >>exit(0);
> >>}
> >>    
> >
> >It works on my x86 box, running snv_33;  what is the contents of stderr
and
> >stdout, and what is the output of "uname -a"?
> >
> >Cheers,
> >- jonathan
> >
> >  
> >>Regards,
> >>Adam Zhang
> >>
> >>Jonathan Adams wrote:
> >>    
> >>>On Mon, Feb 27, 2006 at 02:16:59PM -0800, CHIAN-PHON LIN wrote:
> >>> 
> >>>      
> >>>>Hi,
> >>>>
> >>>>I know that ftruncate() truncates standard output file.
> >>>>Does it also truncate standard error file?
> >>>>   
> >>>>        
> >>>No.
> >>>
> >>> 
> >>>      
> >>>>If not, what is
> >>>>the syntax for truncating standard error file.
> >>>>   
> >>>>        
> >>>You have to re-open stdout as stderr, truncate, then re-open
the original
> >>>stdout.  i.e.:
> >>>
> >>># cat > script.d <<EOF
> >>>#!/usr/sbin/dtrace -s
> >>>
> >>>#pragma D option quiet
> >>>#pragma D option destructive
> >>>
> >>>BEGIN
> >>>{
> >>>	printf("data\n");
> >>>	freopen("/dev/stderr");
> >>>	ftruncate();
> >>>	freopen("");	/* re-open original stdout */
> >>>	printf("more data\n");
> >>>	exit(0);
> >>>}
> >>>EOF
> >>># chmod a+x script.d
> >>># echo foo > stdout
> >>># echo foofoo > stderr
> >>># ls -l std*
> >>>-rw-r--r--   1 root     root           7 Feb 27 14:21 stderr
> >>>-rw-r--r--   1 root     root           4 Feb 27 14:21 stdout
> >>># ./script.d >>stdout 2>>stderr
> >>># ls -l std*
> >>>-rw-r--r--   1 root     root           0 Feb 27 14:26 stderr
> >>>-rw-r--r--   1 root     root          19 Feb 27 14:26 stdout
> >>># cat stdout
> >>>foo
> >>>data
> >>>more data
> >>>#
> >>>
> >>>Cheers,
> >>>- jonathan
> >>>
> >>> 
> >>>      
> >
> >  
-- 
Jonathan Adams, Solaris Kernel Development

Adam Zhang

2006-Mar-01 02:31 UTC

head link

[dtrace-discuss] ftruncate() truncates standard error?

Hi Jonathan,

Yes, you are right. The machine is a little strange.
After using the /fd/2 directly, the script works now.
Thanks!

Regards,
Adam

Jonathan Adams wrote:> On Tue, Feb 28, 2006 at 11:57:15AM +0800, Adam Zhang wrote:
>   
>> Hi Jonathan,
>>
>> The output of ''uname -a'' is:
>> SunOS florida 5.10 Generic_118844-28 i86pc i386 i86pc
>>
>> The contents of stderr and stdout file are:
>> -bash-3.00# more stderr
>> foofoo
>> -bash-3.00# more stdout
>> foo
>> data
>> more data
>>
>> -bash-3.00#
>>
>> This machine is on the SWAN. I will send you the password separately. 
>> Thank you in advance!
>>     
>
> Wacky;  your machine is missing the /dev/std* symlinks:
>
> # ls -l /dev/std*
> -rw-r--r--   1 root     root           0 Feb 28 10:24 /dev/stderr
>
> as opposed to my machine:
>
> # ls -l /dev/std*
> lrwxrwxrwx   1 root     root           4 Feb 10 11:22 /dev/stderr ->
fd/2
> lrwxrwxrwx   1 root     root           4 Feb 10 11:22 /dev/stdin -> fd/0
> lrwxrwxrwx   1 root     root           4 Feb 10 11:22 /dev/stdout ->
fd/1
>
> If you replace "/dev/stderr" with "/dev/fd/2", the
script will work.
>
> I''m not sure why you''re missing the symlinks, but
I''ve removed the bogus
> /dev/stderr on your machine.  Running pkgchk on SUNWcsd (which provides the
> symlinks) revealed:
>
> # pkgchk SUNWcsd
> ERROR: /dev
>     group name <sys> expected <other> actual
> ERROR: /dev/stderr
>     pathname does not exist
> ERROR: /dev/stdin
>     pathname does not exist
> ERROR: /dev/stdout
>     pathname does not exist
> ...
>
> Cheers,
> - jonathan
>
>   
>> Jonathan Adams wrote:
>>     
>>> On Tue, Feb 28, 2006 at 10:31:17AM +0800, Adam Zhang wrote:
>>>  
>>>       
>>>> Hi Jonathan,
>>>>
>>>> I run the script you write on x86, but it looks it
doesn''t work.
>>>>
>>>> -bash-3.00# ./script.d >>stdout 2>>stderr
>>>> -bash-3.00# ls -l std*
>>>> -rw-r--r--   1 root     root           7 Feb 28 10:26 stderr
>>>> -rw-r--r--   1 root     root          36 Feb 28 10:28 stdout
>>>> -bash-3.00# more script.d
>>>> #!/usr/sbin/dtrace -s
>>>>
>>>> #pragma D option quiet
>>>> #pragma D option destructive
>>>> BEGIN
>>>> {
>>>> printf("data\n");
>>>> freopen("/dev/stderr");
>>>> ftruncate();
>>>> freopen("");/* re-open original stdout */
>>>> printf("more data\n");
>>>> exit(0);
>>>> }
>>>>    
>>>>         
>>> It works on my x86 box, running snv_33;  what is the contents of
stderr and
>>> stdout, and what is the output of "uname -a"?
>>>
>>> Cheers,
>>> - jonathan
>>>
>>>  
>>>       
>>>> Regards,
>>>> Adam Zhang
>>>>
>>>> Jonathan Adams wrote:
>>>>    
>>>>         
>>>>> On Mon, Feb 27, 2006 at 02:16:59PM -0800, CHIAN-PHON LIN
wrote:
>>>>>
>>>>>      
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> I know that ftruncate() truncates standard output file.
>>>>>> Does it also truncate standard error file?
>>>>>>   
>>>>>>        
>>>>>>             
>>>>> No.
>>>>>
>>>>>
>>>>>      
>>>>>           
>>>>>> If not, what is
>>>>>> the syntax for truncating standard error file.
>>>>>>   
>>>>>>        
>>>>>>             
>>>>> You have to re-open stdout as stderr, truncate, then
re-open the original
>>>>> stdout.  i.e.:
>>>>>
>>>>> # cat > script.d <<EOF
>>>>> #!/usr/sbin/dtrace -s
>>>>>
>>>>> #pragma D option quiet
>>>>> #pragma D option destructive
>>>>>
>>>>> BEGIN
>>>>> {
>>>>> 	printf("data\n");
>>>>> 	freopen("/dev/stderr");
>>>>> 	ftruncate();
>>>>> 	freopen("");	/* re-open original stdout */
>>>>> 	printf("more data\n");
>>>>> 	exit(0);
>>>>> }
>>>>> EOF
>>>>> # chmod a+x script.d
>>>>> # echo foo > stdout
>>>>> # echo foofoo > stderr
>>>>> # ls -l std*
>>>>> -rw-r--r--   1 root     root           7 Feb 27 14:21
stderr
>>>>> -rw-r--r--   1 root     root           4 Feb 27 14:21
stdout
>>>>> # ./script.d >>stdout 2>>stderr
>>>>> # ls -l std*
>>>>> -rw-r--r--   1 root     root           0 Feb 27 14:26
stderr
>>>>> -rw-r--r--   1 root     root          19 Feb 27 14:26
stdout
>>>>> # cat stdout
>>>>> foo
>>>>> data
>>>>> more data
>>>>> #
>>>>>
>>>>> Cheers,
>>>>> - jonathan
>>>>>
>>>>>
>>>>>      
>>>>>           
>>>  
>>>       
>
>

Reasonably Related Threads

Search for more seemingly similar threads

dtrace discuss - Feb 2006 - trace("") prints hex dump table

[dtrace-discuss] trace("") prints hex dump table

[dtrace-discuss] trace("") prints hex dump table

[dtrace-discuss] ftruncate() truncates standard error?

[dtrace-discuss] ftruncate() truncates standard error?

[dtrace-discuss] ftruncate() truncates standard error?

[dtrace-discuss] ftruncate() truncates standard error?

[dtrace-discuss] ftruncate() truncates standard error?

[dtrace-discuss] ftruncate() truncates standard error?

[dtrace-discuss] ftruncate() truncates standard error?

[dtrace-discuss] ftruncate() truncates standard error?

Reasonably Related Threads