Hans leads police to Nina's body - Mandriva

This is a discussion on Hans leads police to Nina's body - Mandriva ; On Fri, 22 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article , David Powell wrote: >ibuprofin@painkiller.example.tld (Moe Trin) wrote: >>That depends where the fault or lightning strike may occur, and what >>you have to measure against. If the whole ...

+ Reply to Thread
Page 8 of 14 FirstFirst ... 6 7 8 9 10 ... LastLast
Results 141 to 160 of 280

Thread: Hans leads police to Nina's body

  1. Re: [O/T] Hans leads police to Nina's body

    On Fri, 22 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , David Powell wrote:

    >ibuprofin@painkiller.example.tld (Moe Trin) wrote:


    >>That depends where the fault or lightning strike may occur, and what
    >>you have to measure against. If the whole house is momentarily at a
    >>zillion volts, things are fine as long as there isn't something that
    >>is actually a "true ground" voltage.


    >Usually rare these days in residential areas; no so rare in industry.


    Agreed

    >Difficulty is that the regulations are "one size fits all" and it's
    >impossible to rule out the existence of premises where elderly and
    >possibly abandoned copper or lead water pipes, and/or gas pipes or
    >whatever provide a "true earth" over many premises.


    I'm not sure how good the bonding of the gas system pipe are. The
    pipes are "black steel", and the ground consists of a 0.10 inch copper
    wire secured by a band clamp at both ends. Corrosion? Wazzat?"
    Actually, the house painters probably slapped some latex based paint
    over everything when the house got painted last.

    Water lines as grounds are quite chancy here - the pipes in the
    street are concrete. At best, you have the line from your house entry
    point out to the meter, and from there out to the line in the street -
    and even that may not be true. When we bought the house I'm in now, I
    noted a one inch soft copper supply line coming up out of the ground
    (with a 1/3 inch diameter wire bonded to it) and thought "Wow -
    quality!". A year after we moved in, a neighbor mentioned that the
    actual supply pipe underground was polybutylene (a product noted from
    cracking/splitting in time). Later still, I get up one morning, and
    note that the water pressure is low. As I'm backing the car out of the
    garage, I discover the front yard is flooding - badly. Yup. the
    polybutylene line had split. Got some plumbers out and replaced it with
    copper, and as they did so, I noted that the copper stub I had admired
    when I bought the place transitioned to polybutylene about a foot below
    grade. In reality, I was only grounded by the (reportedly 10 foot long)
    utilities ground at the demarc.

    >I don't think that we are very far apart in the principles.


    Agreed

    >I'll bow out now, have the last word if you wish.


    No need for that - sit around and contribute (or at least point fingers
    and snicker)!

    Old guy

  2. Re: Scripting, UPS Selection, etc.

    Moe Trin wrote:
    >> bash seems to have all sorts of functionality... I didn't know it
    >> included string manipulation too.

    >
    > a lot of features
    > got added in simply because they made sense (at the time). Look at
    > all of the options in 'ls' or the perennial example of code bloat 'dig'.


    I suppose it makes more sense to add an option to 'ls' than to write a
    whole new program.

    >> I'm trying to restrain myself and go for clarity instead of
    >> cleverness in scripts, though, even if the result does take a few
    >> milliseconds longer to run.

    >
    > I'll occasionally go for 'clever' but unless that trick winds up as
    > something I use with some regularity, I find it handy to make some
    > effort at documentation. Makes debugging a bit easier.


    I have a few early examples where I was showing off, and they're pretty
    ghastly to look at (one intentionally so).

    In another script that's almost finished, I learned something new --
    using 'cut' before using 'grep' is a LOT faster than the other way
    around. I wouldn't call it "clever," but I did add a comment "note
    order of operations for speed."

    > break: break [n]
    > Exit from within a FOR, WHILE or UNTIL loop. If N is specified,
    > break N levels.
    >
    > I've used this to break out of nested loops - rather than setting bail
    > out flags and testing them everywhere.


    I remember using lots of flags and conditionals in Pascal, when a 'goto'
    would have been much easier to write and follow. However, instructors
    don't look too kindly on a 'goto' in Pascal.

    >> You're right. 'ps 16761' truncates, but both 'ps 16761 | cat' and 'ps
    >> -w 16761' display the entire line. This is in a terminal window on a
    >> KDE desktop... not sure if that matters.

    >
    > Sounds as if your terminal is narrower than 80 char, but none of your
    > ps output is.


    I just checked, and the default terminal window on my system is exactly
    80 characters. Most of my 'ps' output is narrower, but a few of them
    are long enough to have the truncate/wrap issue.

    > I prefer (like many, I suppose) holding stuff to an 80
    > character limit, and many of my terminals are sized to that.


    Goes back to the days of 80 column punch cards, I suppose.

    >> One of the reasons I bought the gadget in the first place was to
    >> determine what size UPS to buy.

    >
    > I'd
    > tend to go with the largest unit I can find before the price break
    > that will not trip the fuse/breakers at max load.


    In my pragmatic way, I figure about $100 will get me a suitable UPS.
    First priority financially, though, is getting the auto body work done
    before the rainy season. In my situation, I don't think getting a UPS
    is urgent.

    Adam

  3. Re: [O/T] Fluorescent Lamps

    Moe Trin wrote:

    > Most of the CFLs seem to have pretty horrible power factors

    [snip]
    > the "150 Watt equivalent" should have PF compensation
    > circuitry of some form.


    I think we discussed this before, but shouldn't it be possible to bring
    the PF of anything closer to 1 by adding a capacitor or inductor in
    parallel?

    > Another problem is that CFLs tend to be RFI
    > (Radio Frequency Interference) generators, (but how many people listen
    > to AM radio now).


    Tried the one near my stereo, no effect.

    I listen to AM radio occasionally. WHVW (950 kcs), "the last locally
    owned independent radio station in the Hudson Valley," has everything.
    Their "oldies" show plays obscure songs as often than hits, they have
    programs for classical music, country, hillbilly, German-language songs,
    local news, and talk/phone-in shows with local people of interest. How
    many stations, AM or FM, can claim that?

    > Electronic dimmers (which are usually just an SCR
    > or SCS with variable RC delay into the cycle) have similar PF and RFI
    > problems, especially at low settings where the cycle is cropped a lot.


    Yep, I noticed the RFI problem there. Affects both commercial AM and
    short wave, more at lower brightnesses.

    > I know that many of the
    > desk and table lamps you buy come with three-way sockets, but it seems
    > the first thing I do when I get time is to replace the sockets with a
    > standard on/off type.


    Why? Regular bulbs work in a three-way socket.

    >> The human eye can get used to all sorts of things. After a while in
    >> the BW darkroom, I didn't even notice how orange the light was.

    >
    > The film sure did (or not as you wish to interpret that).


    I meant the room with the enlargers, not the totally dark rooms for
    loading the developing tanks. The safelights were bright enough to take
    a decent photo by, though I did need a tripod.

    Adam

  4. Re: Scripting, UPS Selection, etc.

    On Sun, 24 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Adam wrote:

    >Moe Trin wrote:


    >> a lot of features got added in simply because they made sense (at
    >> the time). Look at all of the options in 'ls' or the perennial
    >> example of code bloat 'dig'.

    >
    >I suppose it makes more sense to add an option to 'ls' than to write
    >a whole new program.


    /bin/ls -p /bin/ls -F

    (Using the full path to sneak around any shell aliases.)

    >> I'll occasionally go for 'clever' but unless that trick winds up as
    >> something I use with some regularity, I find it handy to make some
    >> effort at documentation. Makes debugging a bit easier.

    >
    >I have a few early examples where I was showing off, and they're pretty
    >ghastly to look at (one intentionally so).


    Maybe because you tend to forget blunders unless there was a lesson
    learnt, I don't recall to many that I've published. I'm certain I've
    created some garbage... But remember one thing about scripts and
    scripting - "get the job done - pretty or efficient can come later if
    needed".

    >In another script that's almost finished, I learned something new --
    >using 'cut' before using 'grep' is a LOT faster than the other way
    >around. I wouldn't call it "clever," but I did add a comment "note
    >order of operations for speed."


    That probably depends on the material you are working with. If the
    lines are long and you only need a few fields, cut | grep might be
    more efficient as you are cutting down the space to search. On the
    other hand, with few records/lines containing the needed data, it
    may be faster to grep | cut which makes cut run on the few lines of
    interest rather than everything. My instructor neighbor is constantly
    beating on his students "know what the data looks like" and reach
    decisions/techniques based on that.

    >> I prefer (like many, I suppose) holding stuff to an 80
    >> character limit, and many of my terminals are sized to that.

    >
    >Goes back to the days of 80 column punch cards, I suppose.


    Try 'pica' - it goes back to type-setting centuries ago.

    >> I'd tend to go with the largest unit I can find before the price
    >> break that will not trip the fuse/breakers at max load.

    >
    >In my pragmatic way, I figure about $100 will get me a suitable UPS.


    My sister recently spent around that for a 750VA unit. I'm not sure
    where she bought it, but it was a UPC.

    >First priority financially, though, is getting the auto body work done
    >before the rainy season.


    Rainy season? We're half way through that here, and they're forecasting
    a significant (40%) chance of thunderstorms this afternoon.

    Old guy

  5. Re: [O/T] Fluorescent Lamps

    On Sun, 24 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Adam wrote:

    >Moe Trin wrote:


    >> Most of the CFLs seem to have pretty horrible power factors

    >[snip]
    >> the "150 Watt equivalent" should have PF compensation
    >> circuitry of some form.

    >
    >I think we discussed this before, but shouldn't it be possible to
    >bring the PF of anything closer to 1 by adding a capacitor or
    >inductor in parallel?


    These types of devices have a leading PF (ELI the ICE man - a
    mnemonic I learned in the 1950s), so an inductor would be called
    for - alternatively, an inductive load such as a classic fluorescent
    lamp with ballast.

    >> Another problem is that CFLs tend to be RFI (Radio Frequency
    >> Interference) generators, (but how many people listen to AM radio
    >> now).

    >
    >Tried the one near my stereo, no effect.
    >
    >I listen to AM radio occasionally.


    Most of the "decent" broadcasters are moving to the FM band here. There
    are 107 AM channels (540-1600 KHz), and just 17 are occupied during the
    day at my house. At least 25 of the 100 FM channels are occupied (more
    because there are several low power "adjacent channel" repeaters to
    cover some shadowed areas).

    >> Electronic dimmers (which are usually just an SCR or SCS with
    >> variable RC delay into the cycle) have similar PF and RFI problems,
    >> especially at low settings where the cycle is cropped a lot.

    >
    >Yep, I noticed the RFI problem there. Affects both commercial AM and
    >short wave, more at lower brightnesses.


    Hmmm, I've got three short wave receivers in the house, and a converter
    that I could install in the car, but I really haven't been using those
    bands for at least ten years. Part of it may be related to the RFI
    problem, as that's been a factor for years.

    >> I know that many of the desk and table lamps you buy come with
    >> three-way sockets, but it seems the first thing I do when I get time
    >> is to replace the sockets with a standard on/off type.


    >Why? Regular bulbs work in a three-way socket.


    About ten or so years ago, we had a minor fire in a three-way socket
    when the lamp was screwed in with to much vigor. The "low" wattage
    contact of the socket made contact with the shell of the lamp. This may
    have been a non-standard shell design (it was a No-Name CFL), but that
    wasn't something I wanted to repeat.

    Old guy

  6. Re: Scripting, UPS Selection, etc.

    Moe Trin wrote:
    >> I suppose it makes more sense to add an option to 'ls' than to write
    >> a whole new program.

    >
    > /bin/ls -p /bin/ls -F
    >
    > (Using the full path to sneak around any shell aliases.)


    Well, -F appends a character to indicate executable, link, pipe, and so
    on, and -p doesn't. Funny you should mention that, as I'd just added a
    comment about using either of those options in a bash script I just
    finished. As soon as (a) I figure out what to do about licensing for a
    medium (230 lines) single-file script (I think the one on
    http://www.gnu.org/prep/maintain/htm...her-Files.html
    should be sufficient) and (b) figure out how to post it on my web site
    with proper line breaks, it will be my first "released" Linux program.
    It's not anything breathtaking, but it does do something useful and
    seems to have one advantage over existing programs. It's my small
    contribution to the OSS community.

    >> I have a few early examples where I was showing off, and they're pretty
    >> ghastly to look at (one intentionally so).

    >
    > Maybe because you tend to forget blunders unless there was a lesson
    > learnt, I don't recall to many that I've published.


    The two I'm thinking of work correctly, but I went to extra effort to
    show off. One is deliberately the worst example of spaghetti code I've
    ever seen.

    >> In another script that's almost finished, I learned something new --
    >> using 'cut' before using 'grep' is a LOT faster than the other way
    >> around. I wouldn't call it "clever," but I did add a comment "note
    >> order of operations for speed."

    >
    > That probably depends on the material you are working with. If the
    > lines are long and you only need a few fields, cut | grep might be
    > more efficient as you are cutting down the space to search. On the
    > other hand, with few records/lines containing the needed data, it
    > may be faster to grep | cut which makes cut run on the few lines of
    > interest rather than everything. My instructor neighbor is constantly
    > beating on his students "know what the data looks like" and reach
    > decisions/techniques based on that.


    Your neighbor has an excellent point. In this instance, the lines have
    several fields, but I only care about the first field, and most of the
    lines are matches. The code ended up as:

    cut -d ' ' -f 1 $OUTFILE | uniq | \
    grep '^'`echo $DNUM | cut -c 1` > $TMP1

    because I want to know all the values that have been used for the first
    field for each line of OUTFILE that starts with the first character of DNUM.

    >> Goes back to the days of 80 column punch cards, I suppose.

    >
    > Try 'pica' - it goes back to type-setting centuries ago.


    On a typewriter, pica is 10 cpi so 80 characters on an 8.5"-wide page is
    pushing things.

    >> First priority financially, though, is getting the auto body work done
    >> before the rainy season.

    >
    > Rainy season? We're half way through that here, and they're forecasting
    > a significant (40%) chance of thunderstorms this afternoon.

    [snip]
    > Typical Southwestern rainy season. Late in the afternoon, thunderstorms
    > were popping up randomly. "We got ours" after sunset - 0.94 inches (24
    > mm), which brings me up to 2.25 inches (57 mm) for the month, and 7.77
    > inches (197 mm) for 2008. Other areas of the valley got anywhere from
    > none to nearly 2 inches (50 mm) - luck of the draw. The official (100
    > year) average for Phoenix is 7.11 inches (181 mm) per year.


    According to weather.com, my local average is 44" per year, and up to
    4.7" per month. To my surprise the rainiest months are May and July,
    even though I've always thought of April and October as the rainy months.

    Adam

  7. Re: [O/T] Fluorescent Lamps

    Moe Trin wrote:
    >>> Most of the CFLs seem to have pretty horrible power factors

    >
    > These types of devices have a leading PF (ELI the ICE man - a
    > mnemonic I learned in the 1950s)


    Could you explain the mnemonic? I didn't learn anything as catchy when
    I studied this in spring '81. In fact, we only covered theoretical
    resistors, capacitors, and inductors. I know nothing in the real world
    has a PF of exactly 1 or 0.

    > Most of the "decent" broadcasters are moving to the FM band here. There
    > are 107 AM channels (540-1600 KHz), and just 17 are occupied during the
    > day at my house. At least 25 of the 100 FM channels are occupied (more
    > because there are several low power "adjacent channel" repeaters to
    > cover some shadowed areas).


    IIRC, my car's AM tuner is 530-1710 kcs, while my home system stops at
    1620. About 9:30 AM Tuesday my car radio picked up over 30 AM stations
    and about 40 FM stations -- not necessarily cleanly, but intelligibly.
    That includes some stations in NYC, Albany, and western Connecticut. Of
    course at home the AM stations are badly affected by RFI.

    Adam

  8. Re: Scripting, UPS Selection, etc.

    On Fri, 29 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Adam wrote:

    >Moe Trin wrote:


    >> /bin/ls -p /bin/ls -F


    >Well, -F appends a character to indicate executable, link, pipe, and
    >so on, and -p doesn't.


    Yeah, but the -p option was never deleted once -F became common.

    >Funny you should mention that, as I'd just added a comment about using
    >either of those options in a bash script I just finished.


    Minor caution - many distributions alias 'ls' trying to be helpful.
    _WITHIN_ scripts that others may use, I tend to do two things - first
    unalias everything (unalias -a), and second, use full pathes which
    bypass an alias (using the command as GNU intended them). ;-)

    >As soon as (a) I figure out what to do about licensing for a medium
    >(230 lines) single-file script (I think the one on


    GNU License-Notices-for-Other-Files

    >should be sufficient)


    That's reasonable.

    >and (b) figure out how to post it on my web site with proper line
    >breaks, it will be my first "released" Linux program.


    Running into the problem of "more than 80 character lines? Normally
    what I do to get around this is to break the line at "convenient"
    places and slap a back-slash appropriately to escape the line break.
    (As you did in the code snippet you included here.)

    >It's not anything breathtaking, but it does do something useful


    Good

    >and seems to have one advantage over existing programs.


    No need to go _that_ far ;-)

    >> That probably depends on the material you are working with. If the
    >> lines are long and you only need a few fields, cut | grep might be
    >> more efficient as you are cutting down the space to search. On the
    >> other hand, with few records/lines containing the needed data, it
    >> may be faster to grep | cut which makes cut run on the few lines of
    >> interest rather than everything. My instructor neighbor is constantly
    >> beating on his students "know what the data looks like" and reach
    >> decisions/techniques based on that.

    >
    >Your neighbor has an excellent point.


    It's sometimes surprising how few people actually look at the "data".
    Often, there are dozens of ways to solve a problem, and some can make
    life a lot easier. Sometimes the steps may be subtle... there is a file
    that lists all RFCs, and gives some information (title, authors, date,
    available format/size, status):

    ===================
    2820 Access Control Requirements for LDAP. E. Stokes, D. Byrne, B.
    Blakley, P. Behera. May 2000. (Format: TXT=18172 bytes) (Status:
    INFORMATIONAL)

    2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001.
    (Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869,
    STD0010) (Status: PROPOSED STANDARD)

    2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format:
    TXT=110695 bytes) (Obsoletes RFC0822) (Status: PROPOSED STANDARD)
    ===================

    Homework question is "how many RFCs are standards, how many are..." and
    so on. Note that because of line wraps, the word 'Status:' may not be
    on the same line as PROPOSED or STANDARD...

    [compton ~]$ zcat rfcs/rfc-index* | sed 's/^$/\%/' | tr -d '\n' | tr
    '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed
    's/.*Status: //' | tr -d '\)' | sort | uniq -c | column
    151 BEST CURRENT PRACTICE 1611 INFORMATIONAL
    135 DRAFT STANDARD 1722 PROPOSED STANDARD
    298 EXPERIMENTAL 84 STANDARD
    216 HISTORIC 909 UNKNOWN
    [compton ~]$

    'zcat' because 'sed' doesn't take compressed file input. The first 'sed'
    inserts an unused character (%) on empty lines. The first 'tr' deletes
    all new-lines, changing the file to one big line - the second 'tr'
    changes the percent signs into a new-line, making one line per RFC
    listing. The 'grep' selects those lines beginning with a number
    (eliminating comments and examples at the start of the file), the next
    'tr' squeezes out duplicate spaces created when the lines were unwrapped,
    the last 'grep' gets rid of the 80 RFCs that were not issued, the last
    'sed' trims off everything up to the space following the colon, while
    the last 'tr' trims off the closing parren. Sort things, count them, and
    display in a columns format. "Simple", no?

    >> Typical Southwestern rainy season. Late in the afternoon, thunderstorms
    >> were popping up randomly. "We got ours" after sunset - 0.94 inches (24
    >> mm), which brings me up to 2.25 inches (57 mm) for the month, and 7.77
    >> inches (197 mm) for 2008. Other areas of the valley got anywhere from
    >> none to nearly 2 inches (50 mm) - luck of the draw. The official (100
    >> year) average for Phoenix is 7.11 inches (181 mm) per year.

    >
    >According to weather.com, my local average is 44" per year, and up to
    >4.7" per month. To my surprise the rainiest months are May and July,
    >even though I've always thought of April and October as the rainy months.


    Well, "April Showers" and all that, but yours is a frontal weather
    pattern, "high"s and "low"s and such parading on by. As a followup
    to my note, Thursday night, there were four major storm cells that
    drifted through near down town. University of Arizona had a brand new
    "indoor" practice stadium under a canvas bubble. That got spread over
    a mile or so - nearly two inches of rain in some places, and gusts to
    over 80 MPH. It was a very impressive light show with almost continuous
    lightning seen from my house about 25 miles away. We got nothing. On
    Friday night, something similar hit us. I only got another 0.57 inches
    of rain, but the soil was soaked, and the high winds blew over a 25'
    tall ~20 year old tree in my back yard, crushing the bird netting
    structure over my small garden, and covering (but not damaging) one of
    the air conditioner compressors. The estimator for the tree service
    will be here between 8 and 11 AM Sunday - who knows when they'll be
    able to remove the remains of the tree. A neighbor had a branch
    ripped off a small tree, and driven IN to a window in the (attached)
    garage door. That was the only visible damage I saw this morning.

    Old guy

  9. Re: [O/T] Fluorescent Lamps

    On Fri, 29 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Adam wrote:

    >Moe Trin wrote:


    >> These types of devices have a leading PF (ELI the ICE man - a
    >> mnemonic I learned in the 1950s)

    >
    >Could you explain the mnemonic? I didn't learn anything as catchy when
    >I studied this in spring '81. In fact, we only covered theoretical
    >resistors, capacitors, and inductors.


    E - voltage, I - current, L - inductive, C - capacitive. Thus. "ELI"
    says Voltage leads current in an inductive circuit, while "ICE" the
    current leads voltage in a capacitive circuit.

    >I know nothing in the real world has a PF of exactly 1 or 0.


    Well, a 1.0 should be possible, for example a carbon composition
    (MIL-R-11) resistor or in the lower resistance ranges of a metal film
    (MIL-R-10509) resistor (or their Established Reliability counterparts
    from MIL-R-39008 and MIL-R-55182). Yes, they both have tiny amounts
    of lead inductance and inter-electrode capacitance, but in general,
    it's close enough to pure resistive up to low VHF. A 0.0 PF (pure
    reactive) is a lot harder to obtain, because of leakage, lead
    inductance and stray capacitance. Chip or pill (lead-less) devices
    tend to be more ideal.

    >> Most of the "decent" broadcasters are moving to the FM band here.
    >> There are 107 AM channels (540-1600 KHz), and just 17 are occupied
    >> during the day at my house. At least 25 of the 100 FM channels are
    >> occupied (more because there are several low power "adjacent
    >> channel" repeaters to cover some shadowed areas).

    >
    >IIRC, my car's AM tuner is 530-1710 kcs, while my home system stops at
    >1620.




    I'm not sure why it would go so high. In the Americas (ITU Region 2),
    the top of the band is 5 KHz above the 1600 KHz channel (in the rest
    of the world, 4.5 KHz above the 1602 KHz channel). In the US, there is
    a "Travelers Aid" channel at 1610 KHz (low power, inductive loop giving
    a range under ~100 feet from the loop, often used at places like
    airports giving directions/reports about available parking, etc.),
    but otherwise the band up to 1800 KHz is maritime mobile and radio
    navigation (the old LORAN A system was in this band).

    >Of course at home the AM stations are badly affected by RFI.


    Two possible causes - CFL/dimmers/computers/TVs causing interference,
    and a directional antenna (loop or loop-stick) in the receiver.

    Old guy

  10. Re: Scripting, UPS Selection, etc.

    On 2008-08-31, Moe Trin wrote:
    ....
    > Minor caution - many distributions alias 'ls' trying to be helpful.
    > _WITHIN_ scripts that others may use, I tend to do two things - first
    > unalias everything (unalias -a),


    That is always the first line in my .bashrc. The habit some
    distros have of aliasing standard commands is stupid and
    dangerous.

    > and second, use full pathes which
    > bypass an alias (using the command as GNU intended them). ;-)


    I never use full paths to standard comamnds. I write scripts that
    may be run on various systems, and the commands are not always in
    the same place.

    > Running into the problem of "more than 80 character lines? Normally
    > what I do to get around this is to break the line at "convenient"
    > places and slap a back-slash appropriately to escape the line break.
    > (As you did in the code snippet you included here.)


    As he did unnecessarily in the snippet. A backslash is not
    necessary after a pipe.

    --
    Chris F.A. Johnson, author |
    Shell Scripting Recipes: | My code in this post, if any,
    A Problem-Solution Approach | is released under the
    2005, Apress | GNU General Public Licence

  11. Re: Scripting, UPS Selection, etc.

    On Sun, 31 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <42a42$48ba3a6b$cef88ba3$32463@TEKSAVVY.COM>, Chris F.A. Johnson wrote:

    >Moe Trin wrote:


    >> Minor caution - many distributions alias 'ls' trying to be helpful.
    >> _WITHIN_ scripts that others may use, I tend to do two things - first
    >> unalias everything (unalias -a),

    >
    > That is always the first line in my .bashrc. The habit some
    > distros have of aliasing standard commands is stupid and
    > dangerous.


    The "unalias -a" in ~/.bashrc has the advantage that a distribution
    errata is unlikely to overwrite that file. None the less, I still
    prefer to avoid setting the alias in the first place if possible[1].

    I _ABSOLUTELY_ agree that the aliasing of standard commands is stupid.

    >> and second, use full pathes which bypass an alias (using the command
    >> as GNU intended them). ;-)

    >
    > I never use full paths to standard comamnds. I write scripts that
    > may be run on various systems, and the commands are not always in
    > the same place.


    That one got beat into me by the security auditor (just as setting an
    absolute PATH in shell scripts that might be run in a non-standard
    environment). Looking at the scripts in /usr/local/bin and ~/.bin, I
    see that roughly 45% of the commands used are in /bin/, about 30%
    are shell built-ins, about 10% are /usr/bin/ and another 10% are
    ~./bin/. As /usr/local/bin and ~/.bin are locally administered, the
    contents will probably differ ("YMMV").

    >> Running into the problem of "more than 80 character lines? Normally
    >> what I do to get around this is to break the line at "convenient"
    >> places and slap a back-slash appropriately to escape the line break.
    >> (As you did in the code snippet you included here.)

    >
    > As he did unnecessarily in the snippet. A backslash is not
    > necessary after a pipe.


    I'd venture that very few people are aware of that. Using the backslash
    is the "expected" method of continuing a line.

    Old guy

    [1] Not as easy as it seems, because many distributions "know better"
    than POSIX or the software author, and do _VERY STUPID_ things to "make
    things easier". This also applies to the id10ts who create all kinds
    windoze-wannabe "helpers" and bells/whistles in their GUI desktops.

  12. Re: [O/T] Fluorescent Lamps

    Moe Trin wrote:
    > E - voltage, I - current, L - inductive, C - capacitive. Thus. "ELI"
    > says Voltage leads current in an inductive circuit, while "ICE" the
    > current leads voltage in a capacitive circuit.


    Thanks, I'll try to remember that. I don't seem to find as much need as
    I used to for electrical engineering things like that.

    > A 0.0 PF (pure
    > reactive) is a lot harder to obtain, because of leakage, lead
    > inductance and stray capacitance.


    Plus, I assume, the resistance of the wire used in an inductor is nonzero.

    >> my car's AM tuner is 530-1710 kcs, while my home system stops at 1620.

    >
    > I'm not sure why it would go so high. In the Americas (ITU Region 2),
    > the top of the band is 5 KHz above the 1600 KHz channel (in the rest
    > of the world, 4.5 KHz above the 1602 KHz channel). In the US, there is
    > a "Travelers Aid" channel at 1610 KHz


    Well, http://www.fcc.gov/mb/audio/amq.html shows US stations up to 1700
    kHz, including some at 1700, and I figure they ought to know.

    >> Of course at home the AM stations are badly affected by RFI.

    >
    > Two possible causes - CFL/dimmers/computers/TVs causing interference,
    > and a directional antenna (loop or loop-stick) in the receiver.


    Both. CFLs near one receiver, electronic dimmer near the other,
    and ferrite loopstick antennas.

    Adam


  13. Re: Scripting, UPS Selection, etc.

    Moe Trin wrote:
    > Minor caution - many distributions alias 'ls' trying to be helpful.


    Including Mandriva, or at least Mandriva 2008.0. cp, df, du, egrep,
    fgrep, grep, ls, mv, and rm have aliases defined.

    > _WITHIN_ scripts that others may use, I tend to do two things - first
    > unalias everything (unalias -a), and second, use full pathes which
    > bypass an alias (using the command as GNU intended them). ;-)


    I just discovered that the aliases don't seem to apply inside a bash script.

    [adam@eris ~]$ alias ls
    alias ls='ls -F --show-control-chars --color=auto'
    [adam@eris ~]$ ls -d D*
    Desktop/ Documents/ Download/ [directory names are blue]
    [adam@eris ~]$ cat t
    #!/bin/bash
    ls -d D*
    [adam@eris ~]$ ./t
    Desktop Documents Download [no colors]
    [adam@eris ~]$

    >> figure out how to post it on my web site with proper line
    >> breaks, it will be my first "released" Linux program.

    >
    > Running into the problem of "more than 80 character lines? Normally
    > what I do to get around this is to break the line at "convenient"
    > places and slap a back-slash appropriately to escape the line break.
    > (As you did in the code snippet you included here.)


    Nope, no lines even near 80 characters, intentionally. The problem is
    the way the web page is displayed. If you right-click on

    http://mysite.verizon.net/adam707/discat

    and select "save target as", it downloads correctly. If you try to
    display it as a web page, it's a mess.

    After downloading, edit the first few variables as described to
    something appropriate for your system, use chmod u+x or a+x to make it
    executable, and move it to a suitable directory.

    >> It's not anything breathtaking, but it does do something useful

    >
    > Good


    It's a bash script for cataloging data CDs and DVDs. Fancier version of
    dumping the directories to a file, with a category and unique number for
    each disc, so search results automatically tell you which discs to pull out.

    >> and seems to have one advantage over existing programs.

    >
    > No need to go _that_ far ;-)


    Its output files are ordinary text files, which can be searched or
    browsed with any program under any OS.

    Incidentally, anyone is welcome to download and use this script, and
    even improve it if you want. Comments from anybody about use, coding
    technique, style, or anything else would be appreciated!

    > It's sometimes surprising how few people actually look at the "data".
    > Often, there are dozens of ways to solve a problem, and some can make
    > life a lot easier.


    In this case, "grep | cut" took about 15 seconds, and "cut | grep" less
    than 1.

    > Homework question is "how many RFCs are standards, how many are..." and
    > so on. Note that because of line wraps, the word 'Status:' may not be
    > on the same line as PROPOSED or STANDARD...
    >
    > [compton ~]$ zcat rfcs/rfc-index* | sed 's/^$/\%/' | tr -d '\n' | tr
    > '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed
    > 's/.*Status: //' | tr -d '\)' | sort | uniq -c | column
    > 151 BEST CURRENT PRACTICE 1611 INFORMATIONAL
    > 135 DRAFT STANDARD 1722 PROPOSED STANDARD
    > 298 EXPERIMENTAL 84 STANDARD
    > 216 HISTORIC 909 UNKNOWN
    > [compton ~]$


    I was actually able to follow that without reading your explanation of
    it! I did have to look up 'zcat', 'tr -s', 'uniq -c' and 'column' though.

    I have a few specific questions about pieces of that, if you (or anyone)
    have the time.

    zcat rfcs/rfc-index* |

    Why not "zcat ~/rfcs/rfc-index*", so you could run it from any directory?

    sed 's/^$/\%/' | tr -d '\n' |

    Wouldn't "tr '\n' ' '" be better, so the words stay separated?

    tr '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' |

    "grep -v" or "grep -iv"?

    sed 's/.*Status: //' | tr -d '\)' |

    Why '\)' instead of ')'?

    sort | uniq -c | column

    > "Simple", no?


    The whole things makes sense to me.

    Adam


  14. Re: Scripting, UPS Selection, etc.

    Chris F.A. Johnson wrote:
    >> _WITHIN_ scripts that others may use, I tend to do two things - first
    >> unalias everything (unalias -a),

    >
    > That is always the first line in my .bashrc. The habit some
    > distros have of aliasing standard commands is stupid and
    > dangerous.


    Mandriva does that for several commands, in /etc/profile.d/alias.sh .

    > I never use full paths to standard comamnds. I write scripts that
    > may be run on various systems, and the commands are not always in
    > the same place.


    As I mentioned in my previous message, apparently aliases don't apply
    within bash scripts.

    Would something like

    `which ls` -l $DIRECTORY

    be a good idea instead?

    >> slap a back-slash appropriately to escape the line break.

    >
    > As he did unnecessarily in the snippet. A backslash is not
    > necessary after a pipe.


    I didn't know that. OTOH I think I'll leave the backslash in, because
    it's clearer, at least for me.

    Thanks for all your comments, Chris! I really appreciate constructive
    suggestions from experts like yourself.

    Adam

  15. Re: Scripting, UPS Selection, etc.

    Moe Trin wrote:
    >> I never use full paths to standard commands. I write scripts that
    >> may be run on various systems, and the commands are not always in
    >> the same place.

    >
    > That one got beat into me by the security auditor (just as setting an
    > absolute PATH in shell scripts that might be run in a non-standard
    > environment).


    Wouldn't something like

    `which ls` -A $DIRECTORY

    invoke 'ls' directly, no matter where it is in $PATH?

    > [1] Not as easy as it seems, because many distributions "know better"
    > than POSIX or the software author, and do _VERY STUPID_ things to "make
    > things easier". This also applies to the id10ts who create all kinds
    > windoze-wannabe "helpers" and bells/whistles in their GUI desktops.


    Well, you can't blame this one on me. Both the script I just finished
    and the next one (the one with the 'case' statement) are strictly CLI.

    Adam

  16. Re: Scripting, UPS Selection, etc.

    On Mon, 01 Sep 2008 17:04:13 -0400, Adam wrote:

    > Nope, no lines even near 80 characters, intentionally. The problem is
    > the way the web page is displayed. If you right-click on
    > http://mysite.verizon.net/adam707/discat
    > and select "save target as", it downloads correctly. If you try to
    > display it as a web page, it's a mess.


    Looks like verizon must be using a M$ web server. I've uploaded a bash
    script to http://www.ody.ca/~dwhodgins/MissingMimesAdd, and it displays
    fine.

    You could install the unix2dos rpm, and use it to convert the linefeeds
    to carriage-return/linefeeds. That would fix the display in a browser,
    but mess it up for anyone using the save target, or wget.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  17. Re: Scripting, UPS Selection, etc.

    On 2008-09-01, Adam wrote:
    > Chris F.A. Johnson wrote:
    >>> _WITHIN_ scripts that others may use, I tend to do two things - first
    >>> unalias everything (unalias -a),

    >>
    >> That is always the first line in my .bashrc. The habit some
    >> distros have of aliasing standard commands is stupid and
    >> dangerous.

    >
    > Mandriva does that for several commands, in /etc/profile.d/alias.sh .


    One of the first things I do after installing Mandriva is to
    comment out the loop in /etc/profile that sources the files in
    /etc/profile.d; it's unnecessary.

    >> I never use full paths to standard comamnds. I write scripts that
    >> may be run on various systems, and the commands are not always in
    >> the same place.

    >
    > As I mentioned in my previous message, apparently aliases don't apply
    > within bash scripts.
    >
    > Would something like
    >
    > `which ls` -l $DIRECTORY
    >
    > be a good idea instead?


    Apart from the fact that 'which' is not standard, and there is at
    least one version in the wild that doesn't work, why bother? Just
    use:

    ls -l "$DIRECTORY"

    >>> slap a back-slash appropriately to escape the line break.

    >>
    >> As he did unnecessarily in the snippet. A backslash is not
    >> necessary after a pipe.

    >
    > I didn't know that. OTOH I think I'll leave the backslash in, because
    > it's clearer, at least for me.


    It also applies to && and ||.

    I like to keep scripts as clean as possible.

    > Thanks for all your comments, Chris! I really appreciate constructive
    > suggestions from experts like yourself.


    You're welcome.

    --
    Chris F.A. Johnson, author |
    Shell Scripting Recipes: | My code in this post, if any,
    A Problem-Solution Approach | is released under the
    2005, Apress | GNU General Public Licence

  18. Re: Scripting, UPS Selection, etc.

    On 2008-09-01, Adam wrote:
    > Moe Trin wrote:
    >> Minor caution - many distributions alias 'ls' trying to be helpful.

    >
    > Including Mandriva, or at least Mandriva 2008.0. cp, df, du, egrep,
    > fgrep, grep, ls, mv, and rm have aliases defined.
    >
    >> _WITHIN_ scripts that others may use, I tend to do two things - first
    >> unalias everything (unalias -a), and second, use full pathes which
    >> bypass an alias (using the command as GNU intended them). ;-)

    >
    > I just discovered that the aliases don't seem to apply inside a bash script.


    By default, they don't. Even if you do turn them on in the script,
    aliases in the calling environment will not have any effect as they
    are not exported.

    It is much better to use functions than aliases. As the bash man
    page says, "For almost every purpose, aliases are superseded by
    shell functions."

    --
    Chris F.A. Johnson, author |
    Shell Scripting Recipes: | My code in this post, if any,
    A Problem-Solution Approach | is released under the
    2005, Apress | GNU General Public Licence

  19. Re: [O/T] Fluorescent Lamps

    On Mon, 01 Sep 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Adam wrote:

    >Moe Trin wrote:


    >> E - voltage, I - current, L - inductive, C - capacitive. Thus. "ELI"
    >> says Voltage leads current in an inductive circuit, while "ICE" the
    >> current leads voltage in a capacitive circuit.

    >
    >Thanks, I'll try to remember that. I don't seem to find as much need
    >as I used to for electrical engineering things like that.


    I think that many of the things we learned way back then are slipping
    away silently. The mnemonics tend to remain much longer - I'm SURE you
    remember the memory aide for resistor color codes ;-)

    >> A 0.0 PF (pure reactive) is a lot harder to obtain, because of
    >> leakage, lead inductance and stray capacitance.

    >
    >Plus, I assume, the resistance of the wire used in an inductor is
    >nonzero.


    True - of course, we're talking "relative" here. At 60 Hertz, a 1000 uH
    hash choke has a reactance of 0.37 Ohms, and a resistance of about a
    half ohm - which is to say not very reactive. At 50 KHz, the resistance
    hasn't changed, but the reactance is 314 Ohms. That's another reason
    why switching power supplies are run at supersonic (and higher)
    frequencies. (Primary reason is that the transformers are smaller.)

    >> I'm not sure why it would go so high. In the Americas (ITU Region 2),
    >> the top of the band is 5 KHz above the 1600 KHz channel (in the rest
    >> of the world, 4.5 KHz above the 1602 KHz channel). In the US, there is
    >> a "Travelers Aid" channel at 1610 KHz

    >
    >Well, http://www.fcc.gov/mb/audio/amq.html shows US stations up to 1700
    >kHz, including some at 1700, and I figure they ought to know.


    That's because I'm no longer in that racket, and my NTIA manual is out of
    date. Yes, that's the Expanded Band Allotment Plan.

    Old guy

  20. Re: Scripting, UPS Selection, etc.

    On Mon, 01 Sep 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Adam wrote:

    >Moe Trin wrote:


    >> Minor caution - many distributions alias 'ls' trying to be helpful.

    >
    >Including Mandriva, or at least Mandriva 2008.0. cp, df, du, egrep,
    >fgrep, grep, ls, mv, and rm have aliases defined.


    Yeah - that drives me nuts, and I hate it when I run into it
    unexpectedly on systems that aren't mine.

    >I just discovered that the aliases don't seem to apply inside a bash
    >script.


    "That depends". You may be being confused by your desktop. An
    'strace -eopen t' (where 't' is the name of your script) might show
    something.

    >[adam@eris ~]$ alias ls
    >alias ls='ls -F --show-control-chars --color=auto'
    >[adam@eris ~]$ ls -d D*
    >Desktop/ Documents/ Download/ [directory names are blue]
    >[adam@eris ~]$ cat t
    >#!/bin/bash
    >ls -d D*
    >[adam@eris ~]$ ./t
    >Desktop Documents Download [no colors]
    >[adam@eris ~]$


    [compton ~]$ alias
    alias vi='vi -T linux'
    [compton ~]$ cat FOO
    #!/bin/bash
    alias
    [compton ~]$ ./FOO
    alias vi='vi -T linux'
    [compton ~]$

    It works that way here because aliases are set in ~/.bashrc. Obviously,
    YMMV.

    >Nope, no lines even near 80 characters, intentionally. The problem is
    >the way the web page is displayed. If you right-click on
    >
    >http://mysite.verizon.net/adam707/discat




    >and select "save target as", it downloads correctly. If you try to
    >display it as a web page, it's a mess.


    I'm not a HTML guy, but yes, I see the difference in the results. If I
    look at it as "source", it comes across as plain (usable) text.
    Otherwise, it renders weird.

    >>> and seems to have one advantage over existing programs.

    >>
    >> No need to go _that_ far ;-)

    >
    >Its output files are ordinary text files, which can be searched or
    >browsed with any program under any OS.


    Actually, that is a major advantage.

    >> Homework question is "how many RFCs are standards, how many are..."
    >> and so on. Note that because of line wraps, the word 'Status:' may
    >> not be on the same line as PROPOSED or STANDARD...


    That source file is ftp://ftp.isi.edu/in-notes/rfc-index.txt

    -rw-r--r-- 1 ftpuser ftpusers 886636 Aug 30 23:45 rfc-index.txt

    [compton ~]$ zwc rfcs/rfc-index.txt-08.31.08.gz
    20084 111107 886706
    [compton ~]$

    > [compton ~]$ zcat rfcs/rfc-index* | sed 's/^$/\%/' | tr -d '\n' | tr
    > '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed
    > 's/.*Status: //' | tr -d '\)' | sort | uniq -c | column


    >I was actually able to follow that without reading your explanation of
    >it! I did have to look up 'zcat', 'tr -s', 'uniq -c' and 'column'
    >though.


    Good! We want you discovering new ideas!

    >I have a few specific questions about pieces of that, if you (or
    >anyone) have the time.
    >
    > zcat rfcs/rfc-index* |
    >Why not "zcat ~/rfcs/rfc-index*", so you could run it from any
    >directory?


    Because the 'rfcs' directory is actually a soft link in my working
    directory that points to an NFS mounted /net/atlantis/usr/share/rfcs/
    directory. Not a really critical item but trying to avoid confusion.

    > sed 's/^$/\%/' | tr -d '\n' |
    >
    >Wouldn't "tr '\n' ' '" be better, so the words stay separated?


    Look at the source file (or the snippets I've provided). Each "item"
    consists of a variable number of lines where only the first one (the
    one with the RFC number) begins at "0". The rest of the lines are
    indented by five spaces.

    > tr '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' |
    >
    >"grep -v" or "grep -iv"?


    The 'i' isn't needed, as the only occurrences are as shown:

    ==============
    0013 Zero Text Length EOF Message. V. Cerf. August 1969. (Format:
    TXT=1070 bytes) (Status: UNKNOWN)

    0014 Not Issued.

    0015 Network subsystem for time sharing hosts. C.S. Carr. September
    1969. (Format: TXT=10695 bytes) (Status: UNKNOWN)
    ==============

    Save two keystrokes verses add one and burn a few more CPU cycles.

    > sed 's/.*Status: //' | tr -d '\)' |
    >
    >Why '\)' instead of ')'?


    That would work here - I have a habit of escaping characters like this
    that _can_ have special meaning to a shell.

    >> "Simple", no?

    >
    >The whole things makes sense to me.


    If you look at the source file, initially you have some ideas that
    maybe "this" will work - and then you run into "special cases" where
    your idea hits something unexpected. Personally, I _like_ the idea
    of "one-liners", as they often are easy to implement and get the job
    done right-away. The other place where they come in handy is when you
    are documenting something, and can use this to (in effect) say "here's
    how I got this data".

    Old guy

+ Reply to Thread
Page 8 of 14 FirstFirst ... 6 7 8 9 10 ... LastLast