public inbox for linux-newbie@vger.kernel.org
 help / color / mirror / Atom feed
* unusual uniq results
@ 2004-09-28 15:09 William Stanard
  2004-09-28 16:11 ` Stone
  0 siblings, 1 reply; 5+ messages in thread
From: William Stanard @ 2004-09-28 15:09 UTC (permalink / raw)
  To: linux-newbie

In doing a demo before a class (Linux Red-hat 2.4.18-14), I used the uniq
command on a file (dup_nums) that consisted of twelve lines, each line
containing a number, from one to 9. I repeated the numbers, 6, 8, and 9.
The std output showed the expected list of numbers, all duplicates
removed. At a student's suggestion, I ran uniq again, but this time
directed the output to the file itself....

uniq dup_num > dup_num

...and, lo and behold, the file dup_num was empty. I checked uniq --help,
info uniq, and man uniq, all to no avail. Shouldn't uniq have removed the
duplicate numbers and written one through 9 to the file?

Bill stanard




-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: unusual uniq results
  2004-09-28 15:09 unusual uniq results William Stanard
@ 2004-09-28 16:11 ` Stone
  2004-09-29 11:07   ` William Stanard
  0 siblings, 1 reply; 5+ messages in thread
From: Stone @ 2004-09-28 16:11 UTC (permalink / raw)
  To: linux-newbie

The redirection takes place before your command.  So basically what
you told the system to do was:

1.  Create the file dup_num.  If the file exists overwrite it.
2.  Redirect stdout of "uniq dup_num" into dup_num.

Since you'd already overwritten the data in dup_num, there was nothing
for uniq to process.

On Tue, 28 Sep 2004 11:09:12 -0400, William Stanard
<wstanard@palmertrinity.org> wrote:
> In doing a demo before a class (Linux Red-hat 2.4.18-14), I used the uniq
> command on a file (dup_nums) that consisted of twelve lines, each line
> containing a number, from one to 9. I repeated the numbers, 6, 8, and 9.
> The std output showed the expected list of numbers, all duplicates
> removed. At a student's suggestion, I ran uniq again, but this time
> directed the output to the file itself....
> 
> uniq dup_num > dup_num
> 
> ...and, lo and behold, the file dup_num was empty. I checked uniq --help,
> info uniq, and man uniq, all to no avail. Shouldn't uniq have removed the
> duplicate numbers and written one through 9 to the file?
> 
> Bill stanard
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
> 



-- 
http://xstonedogx.heroesmarket.net
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: unusual uniq results
  2004-09-28 16:11 ` Stone
@ 2004-09-29 11:07   ` William Stanard
  2004-09-29 12:44     ` Simon Valiquette
  2004-09-29 14:53     ` Yapo Sebastien
  0 siblings, 2 replies; 5+ messages in thread
From: William Stanard @ 2004-09-29 11:07 UTC (permalink / raw)
  To: linux-newbie

I'm confused. To me the > has always meant to take what is to the left of
the sign and redirect its output to whatever is to the right. In my case
this would mean taking the output of uniq dup_num and redirecting it. Can
you set me straight?
-- Bill

Stone <xstonedogx@gmail.com> writes:
>The redirection takes place before your command.  So basically what
>you told the system to do was:
>
>1.  Create the file dup_num.  If the file exists overwrite it.
>2.  Redirect stdout of "uniq dup_num" into dup_num.
>
>Since you'd already overwritten the data in dup_num, there was nothing
>for uniq to process.
>
>On Tue, 28 Sep 2004 11:09:12 -0400, William Stanard
><wstanard@palmertrinity.org> wrote:
>> In doing a demo before a class (Linux Red-hat 2.4.18-14), I used the
>uniq
>> command on a file (dup_nums) that consisted of twelve lines, each line
>> containing a number, from one to 9. I repeated the numbers, 6, 8, and 9.
>> The std output showed the expected list of numbers, all duplicates
>> removed. At a student's suggestion, I ran uniq again, but this time
>> directed the output to the file itself....
>> 
>> uniq dup_num > dup_num


Bill Stanard
Academic Computing
Palmer Trinity School
305.969.4239



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: unusual uniq results
  2004-09-29 11:07   ` William Stanard
@ 2004-09-29 12:44     ` Simon Valiquette
  2004-09-29 14:53     ` Yapo Sebastien
  1 sibling, 0 replies; 5+ messages in thread
From: Simon Valiquette @ 2004-09-29 12:44 UTC (permalink / raw)
  To: William Stanard; +Cc: linux-newbie

William Stanard a écrit :
> I'm confused. To me the > has always meant to take what is to the left of
> the sign and redirect its output to whatever is to the right.

   That's basically what it does.  Actually, it also create an empty 
file or erase it if it already exist.

> In my case
> this would mean taking the output of uniq dup_num and redirecting it. Can
> you set me straight?
> -- Bill
>

   It's the opposite.  It creates the redirection first, even before 
knowing if you ran a valid command.

   What you don't seems to understand, is that the ">" ask the shell to 
create an empty file _before_ executing uniq.  It means that the data in 
"dup_num" are already overwritten when uniq is executed, and thus uniq 
is opening an empty file.


Simon Valiquette
http://gulus.USherbrooke.ca



> Stone <xstonedogx@gmail.com> writes:
> 
>>The redirection takes place before your command.  So basically what
>>you told the system to do was:
>>
>>1.  Create the file dup_num.  If the file exists overwrite it.
>>2.  Redirect stdout of "uniq dup_num" into dup_num.
>>
>>Since you'd already overwritten the data in dup_num, there was nothing
>>for uniq to process.
>>
>>On Tue, 28 Sep 2004 11:09:12 -0400, William Stanard
>><wstanard@palmertrinity.org> wrote:
>>
>>>In doing a demo before a class (Linux Red-hat 2.4.18-14), I used the
>>
>>uniq
>>
>>>command on a file (dup_nums) that consisted of twelve lines, each line
>>>containing a number, from one to 9. I repeated the numbers, 6, 8, and 9.
>>>The std output showed the expected list of numbers, all duplicates
>>>removed. At a student's suggestion, I ran uniq again, but this time
>>>directed the output to the file itself....
>>>
>>>uniq dup_num > dup_num
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: unusual uniq results
  2004-09-29 11:07   ` William Stanard
  2004-09-29 12:44     ` Simon Valiquette
@ 2004-09-29 14:53     ` Yapo Sebastien
  1 sibling, 0 replies; 5+ messages in thread
From: Yapo Sebastien @ 2004-09-29 14:53 UTC (permalink / raw)
  To: linux-newbie

Well ... the main problem is that the bash redirection takes effect before 
uniq is executed. 

When you do "uniq dup_num > dup_num" the following happens :

- the bash redirection operator ">" triggers the opening of dup_num in 
write-only mode (O_WRONLY | O_CREAT | O_TRUNC) to redirect stdout to the 
file, thus truncating dup_num to zero length as the file already exists
- the file dup_num is opened read-only by uniq (O_RDONLY)
- the output stream is assumed by uniq to be stdout (no "OUTFILE" specified)
- each line of dup_num is read and treated by uniq but dup_num is empty 
(truncated to zero length before) so, obviously, the result of uniq is also 
empty.

This is probably not perfectly accurate but is "grosso modo" what happens.
Quote from bash manual (Redirection / Redirecting Output) :
"If the file does not exist it is created; if it does exist it is truncated to 
zero size."

Sebastien

On Wednesday 29 September 2004 11:07, you wrote:
> I'm confused. To me the > has always meant to take what is to the left of
> the sign and redirect its output to whatever is to the right. In my case
> this would mean taking the output of uniq dup_num and redirecting it. Can
> you set me straight?
> -- Bill
>
> Stone <xstonedogx@gmail.com> writes:
> >The redirection takes place before your command.  So basically what
> >you told the system to do was:
> >
> >1.  Create the file dup_num.  If the file exists overwrite it.
> >2.  Redirect stdout of "uniq dup_num" into dup_num.
> >
> >Since you'd already overwritten the data in dup_num, there was nothing
> >for uniq to process.
> >
> >On Tue, 28 Sep 2004 11:09:12 -0400, William Stanard
> >
> ><wstanard@palmertrinity.org> wrote:
> >> In doing a demo before a class (Linux Red-hat 2.4.18-14), I used the
> >
> >uniq
> >
> >> command on a file (dup_nums) that consisted of twelve lines, each line
> >> containing a number, from one to 9. I repeated the numbers, 6, 8, and 9.
> >> The std output showed the expected list of numbers, all duplicates
> >> removed. At a student's suggestion, I ran uniq again, but this time
> >> directed the output to the file itself....
> >>
> >> uniq dup_num > dup_num
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-09-29 14:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-28 15:09 unusual uniq results William Stanard
2004-09-28 16:11 ` Stone
2004-09-29 11:07   ` William Stanard
2004-09-29 12:44     ` Simon Valiquette
2004-09-29 14:53     ` Yapo Sebastien

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox