Subject: [TAG] 2c tip: measuring the temperature in your computer room during the day

From: Yan-Fa Li <[email-masked]>
Date: Wed, 17 Mar 2004 13:12:23 -0800

Hi,

I've found a useful side effect of running smartd on my drives at home 
which I've used for a while now
to monitor the temperature in my apartment.  A lot of newer IDE drives, 
especially IBM/Hitachi's and SCSI
hard disks monitor the drive temperature.  I've found this to be a 
useful way to figure out how hot it is
in my computer room at home :D

Assuming you've already installed smartmontools, this was tested with 
version 5.26:

# smartctl -a /dev/hda | grep 194
194 Temperature_Celsius     0x0002   161   161   000    Old_age   
Always       -       34 (Lifetime Min/Max 20/37)

As you can see the drive is a toasty 34 degrees celsius.  Of about 5-7 
degrees above ambient, it's about 27-29C
or 80-85F in that room right now.  Not great for the equipment but 
survivable.  Anyway, not terribly useful,
but interesting nonetheless :D

Yan
_______________________________________________
TAG mailing list
[email-masked]
http://linuxgazette.net/mailman/listinfo/tag

---

From: "Kapil Hari Paranjape" <[email-masked]>
Date: Fri, 19 Mar 2004 14:33:21 +0530

Hello,

I have always thought that filtering files "in-place" was
not possible from the command line...
...until today---one lives and learns.

  dd if=file bs=4k | filter | dd of=file bs=4k conv=notrunc

Where "file" is the file you want to filter and "filter" 
is the filtering program you want to apply.

Examples:

(a) Use rot13 as the filter and you get (rather minimal) encryption
    of the file contents.

(b) Use tr '[A-Z]' '[a-z]' as the filter and you can downcase a file.

Regards,

Kapil.

P.S. http://www.itworld.com/nl/unix_sys_adm/09252002/ has a perl
     solution.

--

---

From: Thomas Adam <[email-masked]>
Date: Fri, 19 Mar 2004 13:04:04 +0000 (GMT)

> Hello,

Well, Hello :)
 
>   dd if=file bs=4k | filter | dd of=file bs=4k conv=notrunc

Perl/sed/ruby all honour the '-i' flag, which is a started, then just
apply regexps to match anything but the filter expression.

-- Thomas Adam

=====
"The Linux Weekend Mechanic" -- http://linuxgazette.net
"TAG Editor"                 -- http://linuxgazette.net

"<shrug> We'll just save up your sins, Thomas, and punish 
you for all of them at once when you get better. The 
experience will probably kill you. :)"

 -- Benjamin A. Okopnik (Linux Gazette Technical Editor)

___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html
_______________________________________________
TAG mailing list
[email-masked]
http://linuxgazette.net/mailman/listinfo/tag

---

From: Ben Okopnik <[email-masked]>
Date: Fri, 19 Mar 2004 10:39:34 -0500

> is the filtering program you want to apply.

The "buffer" program does exactly the same as the above; the process is
called "reblocking".

buffer < foo | filter > foo

If the file is bigger than 1MB, you'll need to specify a larger queue
with the "-m" option, but that's usually not an issue.

Conversely, as Thomas mentioned, you could use Perl's, etc. "in-place
edit" switch:

# rot13
perl -i -wpe'y/a-zA-Z/n-za-mN-ZA-M/' file

# lc everything
perl -i -wpe'$_=lc' file

* Ben Okopnik * okopnik.freeshell.org * Technical Editor, Linux Gazette *
-=-=-=-=-=o0o=-=-=-=-= <http://linuxgazette.net/> =-=-=-=-=o0o=-=-=-=-=-
_______________________________________________
TAG mailing list
[email-masked]
http://linuxgazette.net/mailman/listinfo/tag

---

From: "Jay R. Ashworth" <[email-masked]>
Date: Fri, 19 Mar 2004 13:44:22 -0500

> buffer < foo | filter > foo

<interrupts self while raising hand to complain>

Oh, cause buffer reads the entire file before the '>' can stomp it?

Well, that's not *exactly* the same... :-)

Doesn't that still depend on order of evaluation by the shell?  Is that
defined?

Cheers,
-- jra
-- 
Jay R. Ashworth                                                [email-masked]
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 647 1274

        "They had engineers in my day, too."  -- Perry Vance Nelson
_______________________________________________
TAG mailing list
[email-masked]
http://linuxgazette.net/mailman/listinfo/tag

---

From: Thomas Adam <[email-masked]>
Date: Fri, 19 Mar 2004 18:57:17 +0000 (GMT)

> Well, that's not *exactly* the same... :-)

What do you mean, Jay?
 
> Doesn't that still depend on order of evaluation by the shell?  Is that

Well, yes....

1. buffer < foo
2. | filer is acted upon
3. Resultant output to file

-- Thomas Adam

=====

---

From: "Jay R. Ashworth" <[email-masked]>
Date: Fri, 19 Mar 2004 13:57:54 -0500

> > Well, that's not *exactly* the same... :-)

Cause of what happens if the thing is interrupted in the middle, among
other thiings.

> 3. Resultant output to file

Well, not necessarily.

A shell could (un)reasonably decide to evaluate the output redirection
(ie: stomp on the file) before the buffer program can read it.  At
best, it might be a race condition between the two sides of the pipe.

I don't think, intuitively, that it's at all reliable, where as I think
the dd approach probably is.

Cheers,
-- jra

---

From: Thomas Adam <[email-masked]>
Date: Fri, 19 Mar 2004 19:16:00 +0000 (GMT)

> best, it might be a race condition between the two sides of the pipe.

Maybe, but that would depend on a number of factors.
 
> the dd approach probably is.

Use degenerative test cases... give it a whirl :)

-- Thomas Adam

=====

---

From: Ben Okopnik <[email-masked]>
Date: Sun, 21 Mar 2004 22:21:27 -0500

> Cause of what happens if the thing is interrupted in the middle, among
 
Much like what happens with Kapil's solution if it's interrupted during
the first pipe, with additional complications if it's interrupted during
the second.

> best, it might be a race condition between the two sides of the pipe.
 
Uh, not any shell that contains a _working_ implementation of IPC. One
that's broken, certainly. Chances are that if time ran backwards, it
probably wouldn't work too well either...

> the dd approach probably is.

Please state the mean and the average probabilities and the relevant
confidence levels for the accuracy of your intuitive approach. The data
generated in the course of your study may or may not be used as grounds
for questioning during your exam. :)

---

From: "Jay R. Ashworth" <[email-masked]>
Date: Mon, 22 Mar 2004 10:14:32 -0500

> the first pipe, with additional complications if it's interrupted during

Actually, if Kapil's solution is interrupted in the middle, you have a
half processed input file.  At least you still *have* some file.

> probably wouldn't work too well either...

Every shell programing I've read in 20 years warns againts that
construct, precisely because most shells *will* set up the redirect
first and stomp the output file.  As for the pipeline, I believe that
most shells exec the last component first.  Maybe bash has changed
that; I remember a warning about it in the Bourne book.

> for questioning during your exam. :)

Ok, I've taked the rifle out of the box under my chair and assembled
it.  Where's the ammo?

Cheers,
-- jra

---

From: Ben Okopnik <[email-masked]>
Date: Sun, 21 Mar 2004 22:14:27 -0500

> Well, that's not *exactly* the same... :-)
 
Hell, Jay, by that standard of nitpickiness, nothing ever is. I mean,
all those microseconds have passed, many electrons have travelled some
distance in their orbit, we've moved along the direction indicated by
the entropy arrow...

The meaning of "exactly" for us humans always means "close enough".

> Doesn't that still depend on order of evaluation by the shell?  Is that

Well, *yeah* - just about as definitively as anything in Bash is.
Otherwise Kapil's method wouldn't work either. Neither would piping
anything through "sort". The left side of the pipe has to terminate
before the right side can do anything with the output; in many cases,
there _is_ no output until just before the left side terminates.

Any conversation that includes "yeah, but csh..." is, in the parlance of
an acquaintance, "right off the bugfuck side of the spectrum."

---

From: "Kapil Hari Paranjape" <[email-masked]>
Date: Mon, 22 Mar 2004 11:21:52 +0530

Hi,

Just a few additional remarks:

(a) perl, python and vi/ex do offer alternate solutions ...  but see below.

(b) I couldn't locate "buffer"---where do I find it?

(c) Just to defend the "dd" solution a bit:

  When the "dd" command-line given in the earlier mail is terminated
  (for any reason like a Control-C), it outputs the number of blocks 
  read/written. Thus, the intrepid user can restart the process by
  modifying it with suitable "seek" and "skip" commands. Of course, this
  assumes that the filter operates on data sizes less than 4k
  independently.

I became aware of this "dd" procedure while trying to (yes I'm crazy)
encrypt one entire disk partition in-place. The problem with the other
solutions is that they require a lot of memory to run.

As far reading and writing to pipes is concerned, here is how I
understand it---please correct me if I am wrong. The kernel has its
own *internal* settings on how much data is buffered before a writing
process is put at the back of the queue and the reading process is woken
up. Thus killing any one process in the "dd" pipeline could only result
in *less* data being written than was read---an error from which one can
recover as described above.

Regards,

Kapil.

P.S. The solutions above are not my own. You too can (if you run Debian)
install/check out "cryptofs" the package created by Max Voezler. This
uses the "aespipe" filter (also by the same author) which encrypts
stdin using AES and dumps the encrypted data to stdout.

P.P.S. For the curious. Yes, indeed! I did manage to encrypt my "/home"
partition and perhaps more importantly *use* it in the cryptofs mode.
There is already a lot of documentation at LDP on this.

-- 
..you could spend *all day* customizing the title bar.  Believe me.  I
speak from experience.
	-- Matt Welsh
--
_______________________________________________
TAG mailing list
[email-masked]
http://linuxgazette.net/mailman/listinfo/tag

---

From: Thomas Adam <[email-masked]>
Date: Mon, 22 Mar 2004 08:45:14 +0000 (GMT)

> Hi,

Hello, Kapil.
 
> (b) I couldn't locate "buffer"---where do I find it?

Oddly enough, under Debian it is in the 'buffer' package.

>   (for any reason like a Control-C), it outputs the number of blocks
             ^^^^^^^^^^^^^^^^^^^^^^^
That would be a cool idea to do!
 
>   modifying it with suitable "seek" and "skip" commands. Of course, this

See the "-S", "-s", and "-z" to buffer(1) :)

> solutions is that they require a lot of memory to run.

Yeah, but then one would use a proper filesystem that encrypted data for
you.

> recover as described above.

That supports what I have read.

-- Thomas Adam

=====

---

From: "Kapil Hari Paranjape" <[email-masked]>
Date: Mon, 22 Mar 2004 16:04:42 +0530

> Oddly enough, under Debian it is in the 'buffer' package.

Ah! Thanks! Why is it that the last place one looks is under one's nose?!

> Yeah, but then one would use a proper filesystem that encrypted data for

It is not clear whether encryption belongs with the filesystem or with
the underlying block device. I was looking at "loop-aes" and
"cryptoloop" that work with the block device.

Regards,

Kapil.

-- 
The Universe is populated by stable things.
		-- Richard Dawkins

The Virtual Universe (on the other hand) is
	populated by buggy things.
		-- my response.
--
_______________________________________________
TAG mailing list
[email-masked]
http://linuxgazette.net/mailman/listinfo/tag

---

From: Ben Okopnik <[email-masked]>
Date: Mon, 22 Mar 2004 11:05:41 -0500

> recover as described above.

Since the source and the target file are the same, wouldn't you end up
with some truncated version of your data (i.e., the source being gone no
matter what)? It seems to me that the difference between complete
destruction of data and truncation of it at some random point can only
matter theoretically, except in a vanishingly small number of
situations.

---

From: "Jay R. Ashworth" <[email-masked]>
Date: Mon, 22 Mar 2004 11:07:44 -0500

> matter theoretically, except in a vanishingly small number of

No, you wouldn't.

The target side dd is doing *random access*.

It writes the blocks sequentially, but it writes them *into* the
standing file, one at a time, without touching the blocks around them.  
Likewise on the read side.  The killer is the *redirection*, which his
approach does not use, at all.  Not the pipe.

Cheers,
-- jra

---

From: Ben Okopnik <[email-masked]>
Date: Mon, 22 Mar 2004 11:40:19 -0500

> approach does not use, at all.  Not the pipe.
 
AH. I hadn't realized that. In that case, I agree; there's a large
difference. I've just tried it on a 100MB file I've made up for the
purpose, and it seems that you're right.

---

From: "Jay R. Ashworth" <[email-masked]>
Date: Mon, 22 Mar 2004 12:32:07 -0500

> purpose, and it seems that you're right.

I thought it was an incredibly clever approach that I should have
though of 20 years ago.  :-)

Cheers,
-- jra

---

From: "Jay R. Ashworth" <[email-masked]>
Date: Mon, 22 Mar 2004 10:10:31 -0500

> The meaning of "exactly" for us humans always means "close enough".

Well, in this case, my point was that I question whether it's "close
enough", particularly to end up in a tip...

> there _is_ no output until just before the left side terminates.

In fact I think that's wrong: I don't think the dd method *does* depend
on order of eval; the writing copy of dd can't try to write a block
until it *has* it, so I believe that that method is *guaranteed* never
to stomp data.

> an acquaintance, "right off the bugfuck side of the spectrum."

Three sigma West of ridiculous, yes.  Did *I* mention csh?  :-)

Cheers,
-- jra

---

From: Ben Okopnik <[email-masked]>
Date: Mon, 22 Mar 2004 10:59:12 -0500

> enough", particularly to end up in a tip...
 
A number of folks I know, including myself (on the very rare occasion
that I need it) use the "buffer" method. [shrug] Seems to work fine in
practice.

> until it *has* it, so I believe that that method is *guaranteed* never

So interrupting the "reader" side of "dd" won't stomp anything, but the
writing side will - OK. I don't see a real difference (although I see a
theoretical one), particularly since I don't make a practice of pounding
"Ctrl-C" immediately after launching a buffered process.

> Three sigma West of ridiculous, yes.  Did *I* mention csh?  :-)

Nope. Just doing preventive maintenance. :)

> RFC 2100

Oh GHODS. Jay, you're an incarnation of Evil in the disguise of a
harmless geek. _And_ your scansion limps. :)))

---

From: Jason Creighton <[email-masked]>
Date: Mon, 22 Mar 2004 18:42:01 -0700

On Sun, 21 Mar 2004 22:14:27 -0500, 

> The meaning of "exactly" for us humans always means "close enough".

How close is close enough? Is 3 "close enough" to PI? 3.1? 3.14?
3.14159265358979? The answer is, of course, "it depends". If you're like
me (by which I mean: bad at mental math) and trying to figure out the
area of a circle in your head, you will find it much easier to grab a
handy approximation.[1]

So the question here is, "for *this* problem, does it matter if the
entire file is read by buffer?". There are some cases (most notably,
very large files.) where you would not want to read the whole file.
There are other cases where it simply doesn't matter.

[1] OTOH, if you are working for MicroSoft, 1.234 will do nicely. The
numbers are in ascending order, which looks much nicer and does not
unnecessarily confuse users like "3.14159265358979" does. Why, after
all, should we have to understand irrational numbers to use a computer?
That may have been the case under the evil CLI with DOS, but not in the
modern, happy, user-friendly world that today's MicroSoft products make
possible!

Jason Creighton

---

From: Ben Okopnik <[email-masked]>
Date: Tue, 23 Mar 2004 15:19:41 -0500

> all, should we have to understand irrational numbers to use a computer?

We don't have to be irrational at all - Micr0s0ft can do it for us,
*and* do it professionally! I mean, why take chances on doing it
yourself, when for only $399.95 plus yearly renewals, you too can...
321o4ui329eupeojd^H^hjijq^+++ LOST CARRIER