Hans leads police to Nina's body - Mandriva

This is a discussion on Hans leads police to Nina's body - Mandriva ; On Mon, 01 Sep 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article , Adam wrote: >Moe Trin wrote: >>> I never use full paths to standard commands. I write scripts that >>> may be run on various systems, and the ...

+ Reply to Thread
Page 9 of 14 FirstFirst ... 7 8 9 10 11 ... LastLast
Results 161 to 180 of 280

Thread: Hans leads police to Nina's body

  1. 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:


    >>> 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?


    Maybe - but the real key is _which_ ls? 'which' (depending on
    which one you are running) shows only the first target in the PATH.

    [compton ~]$ echo $PATH
    /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/ibuprofin/bin
    [compton ~]$

    IN MANY CASES, the path is set up with system directories first, and
    the user's own (personal) bin last. But anyone can set their path as
    they wish

    [compton ~]$ PATH="/something/nefarious:/home/ibuprofin/bin:
    /usr/local/bin:/bin:/usr/bin"
    [compton ~]$ echo $PATH
    /something/nefarious:/home/ibuprofin/bin:/usr/local/bin:/bin:/usr/bin
    [compton ~]$

    and if one of your users does that and then asks you (as root) for help
    with some predictable problem, you may well be screwed/r00ted/had
    rather nicely. It wouldn't be the first time someone has had root
    stolen through a trojan program located earlier in the PATH than the
    "real" program.

    Old guy

  2. Re: Scripting, UPS Selection, etc.

    On Tue, 02 Sep 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <75c7b$48bcaaf5$cef88ba3$12018@TEKSAVVY.COM>, Chris F.A. Johnson wrote:

    >On 2008-09-01, Adam wrote:


    >> Chris F.A. Johnson wrote:


    >> 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?


    Likewise, 'which' only shows the first occurrence of a command in the
    PATH, not all of them. It may also not show functions or aliases.

    > use:
    >
    >ls -l "$DIRECTORY"


    "Practical Unix & Internet Security, 3rd Edition", Garfinkel, Spafford,
    Schwartz, ISBN 0-596-00323-4 (P'Reilly) pg 113.

    >>>> 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.


    I think that's the reason I use it too.

    > It also applies to && and ||.


    Presumably because the '|', '&&' and '||' are invoking subshells ?

    > I like to keep scripts as clean as possible.


    There is that, but I'm also looking at the possible mis-interpretation.

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


    Seconded.

    Old guy

  3. Re: Scripting, UPS Selection, etc.

    On 2008-09-01, 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.


    The server is incorrectly sending the page as text/html, so the
    browser is rendering it as such.

    --
    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

  4. Re: Scripting, UPS Selection, etc.

    On 2008-09-02, Moe Trin wrote:
    > On Tue, 02 Sep 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    ><75c7b$48bcaaf5$cef88ba3$12018@TEKSAVVY.COM>, Chris F.A. Johnson wrote:

    ....
    >>>>> 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.

    >
    > I think that's the reason I use it too.
    >
    >> It also applies to && and ||.

    >
    > Presumably because the '|', '&&' and '||' are invoking subshells ?


    No, && and || do not invoke subshells; they do expect to be
    followed by a command, and whitespace is allowed before that
    command.

    >> I like to keep scripts as clean as possible.

    >
    > There is that, but I'm also looking at the possible mis-interpretation.


    What misinterpretations?

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

    >
    > Seconded.


    --
    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

  5. Re: Scripting, UPS Selection, etc.

    On Tue, 02 Sep 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Chris F.A. Johnson wrote:

    >Moe Trin wrote:


    >> Chris F.A. Johnson wrote:


    >>> It also applies to && and ||.

    >>
    >> Presumably because the '|', '&&' and '||' are invoking subshells ?

    >
    > No, && and || do not invoke subshells; they do expect to be
    > followed by a command, and whitespace is allowed before that
    > command.


    Looking at the man page, that's certainly not obvious.

    A list is a sequence of one or more pipelines separated by one of the
    operators ;, &, &&, or ||, and optionally terminated by one of
    ;, &, or .
    Of these list operators, && and || have equal precedence,
    followed by ; and &, which have equal precedence.
    A sequence of one or more newlines may appear in a list instead
    of a semicolon to delimit commands.

    The Bash Reference Guide
    (http://www.gnu.org/software/bash/manual/bashref.txt.gz) also doesn't
    seem to mention this further. Is it POSIX behavior?

    Are you referring to this as an IFS?

    >>> I like to keep scripts as clean as possible.

    >>
    >> There is that, but I'm also looking at the possible mis-interpretation.

    >
    > What misinterpretations?


    What we're discussing here. I think that most people who have received
    some form of training are aware of escaping a newline to make a
    continuation, but unless I'm being particularly dense, I don't see the
    "backslash not needed" statement in any of the references I have handy.

    Old guy

  6. Re: Scripting, UPS Selection, etc.

    On 2008-09-04, Moe Trin wrote:
    > On Tue, 02 Sep 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    >, Chris F.A. Johnson wrote:
    >>Moe Trin wrote:
    >>> Chris F.A. Johnson wrote:

    >
    >>>> It also applies to && and ||.
    >>>
    >>> Presumably because the '|', '&&' and '||' are invoking subshells ?

    >>
    >> No, && and || do not invoke subshells; they do expect to be
    >> followed by a command, and whitespace is allowed before that
    >> command.

    >
    > Looking at the man page, that's certainly not obvious.
    >
    > A list is a sequence of one or more pipelines separated by one of the
    > operators ;, &, &&, or ||, and optionally terminated by one of
    > ;, &, or .
    > Of these list operators, && and || have equal precedence,
    > followed by ; and &, which have equal precedence.
    > A sequence of one or more newlines may appear in a list instead
    > of a semicolon to delimit commands.


    Do you put a backslash after ';' or '&'? No? Then why put one
    after '&&' or '||'?

    A backslash is only needed when the next line would otherwise be
    interpreted as a new command.

    > The Bash Reference Guide
    > (http://www.gnu.org/software/bash/manual/bashref.txt.gz) also doesn't
    > seem to mention this further. Is it POSIX behavior?
    >
    > Are you referring to this as an IFS?


    No. That's another topic altogether.

    >>>> I like to keep scripts as clean as possible.
    >>>
    >>> There is that, but I'm also looking at the possible mis-interpretation.

    >>
    >> What misinterpretations?

    >
    > What we're discussing here. I think that most people who have received
    > some form of training are aware of escaping a newline to make a
    > continuation, but unless I'm being particularly dense, I don't see the
    > "backslash not needed" statement in any of the references I have handy.


    Nor any "backslash required".

    --
    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

  7. Re: [O/T] Fluorescent Lamps

    Moe Trin wrote:
    > 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 ;-)


    Actually I don't think I ever learned them! I did a lot more with
    theoretical resistors than actual ones. IIRC I was always looking at
    the code chart then picking through my pile to find the right one.

    > 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.)


    Ah, okay. I have only a vague understanding of how a switching power
    supply works, but enough to know I'm not supposed to be tinkering with them.

    >> 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.


    FWIW, my car radio goes up to 1710 kHz, and there are stations at 1600,
    1660, and 1680.

    Adam


  8. Re: Scripting, UPS Selection, etc.

    > On 2008-09-01, 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.


    David W. Hodgins wrote:
    > 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.


    Thanks, Dave, but I don't think that's it. I tried converting it to
    CR-LF and posted it and it was still a mess.

    Chris F.A. Johnson wrote:
    > The server is incorrectly sending the page as text/html, so the
    > browser is rendering it as such.


    Thanks, Chris, I suspect that's it. Is that something I can fix? I'll
    ask about this over in 0.verizon.linux too.

    Adam



  9. Re: Scripting, UPS Selection, etc.

    Moe Trin wrote:
    >> 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 find that practically every system besides mine has some unexpected
    surprises. A few days ago I found myself in front of a Mac and had
    almost no idea what to do.

    >> 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.


    New command to me -- it showed a lot of things, but it looks like it
    mostly opens locale files.

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

    I'll have to figure those out.

    >> right-click on http://mysite.verizon.net/adam707/discat
    >> and select "save target as"

    [snip]
    >> 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.


    Yep, I know. :-) It also cuts development time for the output viewing
    routines down to zero.

    >> [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!


    Oh, I'm discovering all sorts of new things. 'tr -s' would have worked
    nicely in 'discat' (the script I just finished, which there has to be a
    better name for). And I hope you've noticed that while I ask a lot of
    questions, I only ask each question /once/.

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

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

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


    I had the same reason for all three questions: can you be 100% sure that
    the input data will always be in exactly the correct format?

    Adam


  10. Re: Scripting, UPS Selection, etc.

    On 2008-09-05, Adam wrote:
    ....
    > Chris F.A. Johnson wrote:
    >> The server is incorrectly sending the page as text/html, so the
    >> browser is rendering it as such.

    >
    > Thanks, Chris, I suspect that's it. Is that something I can fix? I'll
    > ask about this over in 0.verizon.linux too.


    You should be able to do it in .htaccess

    --
    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: [O/T] Fluorescent Lamps

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

    >Moe Trin wrote:


    >> 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 ;-)

    >
    >Actually I don't think I ever learned them! I did a lot more with
    >theoretical resistors than actual ones. IIRC I was always looking at
    >the code chart then picking through my pile to find the right one.


    I won't provide it, as it's very politically incorrect, but it begins
    with the words 'Bad Boys' for black, brown, red, orange, yellow,
    green, blue, violet, gray, white (and don't forget the tolerance band
    that 'gold' is better than 'silver' or 'nothing'). But then, there
    were only 24 values in the 5 percent decades (12 in the 10 percent, 6
    in the 20 percent), so there weren't that many combinations to look at.

    >> That's another reason why switching power supplies are run at
    >> supersonic (and higher) frequencies. (Primary reason is that the
    >> transformers are smaller.)

    >
    >Ah, okay. I have only a vague understanding of how a switching power
    >supply works, but enough to know I'm not supposed to be tinkering with
    >them.


    Well, the main reason is that there is lots of ZAPS!!! in there, and
    that can be painful.

    >> Yes, that's the Expanded Band Allotment Plan.
    >>

    >FWIW, my car radio goes up to 1710 kHz, and there are stations at 1600,
    >1660, and 1680.


    My wife has the newer car (mine is ancient), and after I got the
    manual out, I was able to see how to get the darn thing to scan for AM
    stations. Nothing. A look at a search engine shows the nearest
    stations are in the LA area.

    Old guy

  12. Re: Scripting, UPS Selection, etc.

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

    >Moe Trin wrote:


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

    >
    >I find that practically every system besides mine has some unexpected
    >surprises. A few days ago I found myself in front of a Mac and had
    >almost no idea what to do.


    Simple - I call 4622 (Mac Support) and tell them to look at this
    system. (We still have a few Macs floating about - at least they are
    now running OSX 10.x, so I can sorta fake it if needed. I took a class
    years ago, and had extremely limited knowledge of System 7, but that
    was emergency only.)

    >> An 'strace -eopen t' (where 't' is the name of your script) might
    >> show something.

    >
    >New command to me -- it showed a lot of things, but it looks like it
    >mostly opens locale files.


    open("../..", O_RDONLY|O_NONBLOCK) = 3
    open("/home/ibuprofin/.bashrc", O_RDONLY) = 3
    --- SIGCHLD (Child exited) ---
    open("./FOO", O_RDONLY) = 3

    Here, you can see it looking at my .bashrc

    >>> 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!

    >
    >Oh, I'm discovering all sorts of new things. 'tr -s' would have worked
    >nicely in 'discat' (the script I just finished, which there has to be a
    >better name for).


    Again - this is why I (among others) post command sequences, so that
    people can see things and think "hey, that's a useful command".

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

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

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


    >I had the same reason for all three questions: can you be 100% sure
    >that the input data will always be in exactly the correct format?


    As stated - "know what the data looks like". For example, the 'tr'
    you propose would work, BUT it sticks a space at the beginning of
    each line, requiring the grep to change from "grep '^[0-9]'" to
    "grep '^ [0-9]'" to compensate. As for the case sensitivity,

    [selene ~]$ zgrep -i issued /usr/share/rfcs/rfc-index.txt-08.31.08.gz |
    cut -c5- | sort | uniq -c
    80 Not Issued.
    1 ## Not Issued.
    [selene ~]$

    This is something you'd notice while looking through the file trying
    to figure how you're going to get the data out of it.

    Old guy

  13. script as web page SOLVED (was: Scripting, UPS Selection, etc.)

    Chris F.A. Johnson wrote:
    >>> The server is incorrectly sending the page as text/html, so the
    >>> browser is rendering it as such.

    >> Thanks, Chris, I suspect that's it. Is that something I can fix? I'll
    >> ask about this over in 0.verizon.linux too.

    >
    > You should be able to do it in .htaccess


    Thanks, it looks like that would do it. I also found out that Verizon's
    server uses the file extension to determine the page type, so "file.txt"
    displays as text, "file.sh" displays as shell script ("Open or save?"
    box pops up), and so on. Apparently files with no extension are assumed
    to be HTML.

    Adam

  14. Re: [O/T] Fluorescent Lamps

    Moe Trin wrote:
    >> Ah, okay. I have only a vague understanding of how a switching power
    >> supply works, but enough to know I'm not supposed to be tinkering with
    >> them.

    >
    > Well, the main reason is that there is lots of ZAPS!!! in there, and
    > that can be painful.


    Power supplies and monitors both. It reminds me of a story I read about
    a guy who used to have a wife and daughter until he saved thirty bucks
    by fixing his own brakes.

    >> FWIW, my car radio goes up to 1710 kHz, and there are stations at 1600,
    >> 1660, and 1680.

    >
    > My wife has the newer car (mine is ancient), and after I got the
    > manual out, I was able to see how to get the darn thing to scan for AM
    > stations. Nothing. A look at a search engine shows the nearest
    > stations are in the LA area.


    Those stations were too weak for "scan", but by tuning manually I could
    tell there were some sort of stations at those frequencies over the noise.

    Adam

  15. Re: Scripting, UPS Selection, etc.

    Moe Trin wrote:
    >> A few days ago I found myself in front of a Mac and had
    >> almost no idea what to do.

    >
    > Simple - I call 4622 (Mac Support) and tell them to look at this
    > system.


    In this case, AFAIK it was running normally. I was still almost stumped
    briefly.

    >> Oh, I'm discovering all sorts of new things. 'tr -s' would have worked
    >> nicely in 'discat' (the script I just finished, which there has to be a
    >> better name for).

    >
    > Again - this is why I (among others) post command sequences, so that
    > people can see things and think "hey, that's a useful command".


    Someone in another NG suggested some specific improvements to 'discat'
    that would speed it up, mostly by using variables instead of temporary
    files. And I can see other optimizations I could make, using some bash
    builtins instead of external functions. However, I figure that the
    current script does what it's supposed to well enough, and won't be
    invoked that often anyway, so speed improvements can wait until I have
    some other reason to tinker with it, like adding additional
    functionality. I'd like to get on to another script (the one with
    'case' that we discussed), because there doesn't seem to be anything
    else available that does what I want that script to do.

    Adam

  16. Re: [O/T] Fluorescent Lamps

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

    >Moe Trin wrote:


    >> Well, the main reason is that there is lots of ZAPS!!! in there,
    >> and that can be painful.

    >
    >Power supplies and monitors both. It reminds me of a story I read
    >about a guy who used to have a wife and daughter until he saved
    >thirty bucks by fixing his own brakes.


    Cathode Ray Tube displays, whether for computers or television usually
    have lots of ZAPS in them. That's why the glass that makes up the
    viewable surface is leaded. If you start pulling those electrons with
    more than about 25 KV, you are likely generating X-Rays. Some of the
    original shadow-mask color tubes like the 21AXP22A were designed to
    operate with up to 27.5 KV on the "anode". Not much current behind
    it (less than 2 mil-amps), but don't get to close!

    >>> FWIW, my car radio goes up to 1710 kHz, and there are stations at
    >>> 1600, 1660, and 1680.

    >>
    >> My wife has the newer car (mine is ancient), and after I got the
    >> manual out, I was able to see how to get the darn thing to scan for
    >> AM stations. Nothing. A look at a search engine shows the nearest
    >> stations are in the LA area.

    >
    >Those stations were too weak for "scan", but by tuning manually I
    >could tell there were some sort of stations at those frequencies over
    >the noise.


    Hmmm... 1600 appears to be a 1 KW in Oneida, 1660 might be a 10 KW in
    Jersey City, and 1680 a 10/1 KW near Philadelphia. According to that
    FCC page you cited, the nearest stations to me are over 300 miles away
    (Moreno Valley, Tijuana, and Torrance on 1670, 1700, and 1650 KHz
    respectively), and I can't even detect them in the noise.

    Old guy

  17. Re: Scripting, UPS Selection, etc.

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

    >Someone in another NG suggested some specific improvements to 'discat'
    >that would speed it up, mostly by using variables instead of temporary
    >files. And I can see other optimizations I could make, using some bash
    >builtins instead of external functions. However, I figure that the
    >current script does what it's supposed to well enough, and won't be
    >invoked that often anyway, so speed improvements can wait until I have
    >some other reason to tinker with it, like adding additional
    >functionality.


    Get the job done. Efficiency and pretty can come later if needed.

    You run into this fairly frequently.

    >I'd like to get on to another script (the one with 'case' that we
    >discussed), because there doesn't seem to be anything else available
    >that does what I want that script to do.


    That's as good of an excuse as I've ever heard.

    Old guy

  18. Re: [O/T] Fluorescent Lamps

    Moe Trin wrote:
    >>>> FWIW, my car radio goes up to 1710 kHz, and there are stations at
    >>>> 1600, 1660, and 1680.

    >
    > Hmmm... 1600 appears to be a 1 KW in Oneida, 1660 might be a 10 KW in
    > Jersey City, and 1680 a 10/1 KW near Philadelphia. According to that
    > FCC page you cited, the nearest stations to me are over 300 miles away
    > (Moreno Valley, Tijuana, and Torrance on 1670, 1700, and 1650 KHz
    > respectively), and I can't even detect them in the noise.


    General queries: http://www.fcc.gov/mb/audio/amq.html

    My area:
    http://www.fcc.gov/fcc-bin/amq?state...2=&EW=W&size=9

    I'd guess 1600 kHz is WWRL, 25/5 kW in NYC. 1660 might be WWRU, 10 kW
    in Jersey City. 1680 (Spanish) could be WTTM, 10/1 kW in Lindenwold NJ.
    I'm surprised that I can't get anything from any of the stations at 1700.

    Adam

  19. Re: [O/T] Fluorescent Lamps

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

    >I'm surprised that I can't get anything from any of the stations at 1700.


    What stations? That web page only lists four stations in the US (Des
    Moines, Huntsville, Brownsville and Richardson). There are four items
    in New York state, and three of those (Stony Point Town, Monsey, and
    town of Haverstraw) are applications, not actual licensed stations -
    note the lack of call letters, and the "APP" (instead of "LIC") in the
    field to the left of the town name. The fourth listing - WRCR - is
    also an application as they're currently on 1300 KHz in Spring Valley
    with much lower power.

    You should also note that a significant number of stations have
    directional antenna pattern - more often at night. One station I
    listen to on occasion (KGME) is 5 KW omni during the day, but
    changes to a Southeasterly beamed pattern sunset to sunrise. I have
    no problem hearing them in the day, but I'm 17 miles Northeast of them,
    and at night, they're down in the mud.

    Old guy

  20. Re: Scripting, UPS Selection, etc.

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

    >Moe Trin wrote:


    >> Get the job done. Efficiency and pretty can come later if needed.
    >>
    >> You run into this fairly frequently.

    >
    >Yep, and not just with computers. There are lots of things that could
    >be tinkered with endlessly. I have pretty high standards for what I do,
    >but I know when to be satisfied with "good enough." The script works,
    >and doesn't look amateurish, and that's good enough for now.


    The other problem is running into the law of diminishing returns.
    Most of us will spend an unrealistic amount of time on a script -
    six hours on a script that takes ten seconds to run, and is used once
    a quarter or similar, but that's often a bit of pleasure mixed in
    with practicality. After all, some of these things are done so
    infrequently, it's easier to have a script (even a cron-job) because
    you can't remember what you should do, never mind how.

    >>> there doesn't seem to be anything else available that does what I
    >>> want that script to do.

    >>
    >> That's as good of an excuse as I've ever heard.

    >
    >"Excuse"? :-) Task A can now be done by a script that may be slow,
    >but it gets done. Task B has no simple way to get done yet. Pretty
    >obvious choice to me!


    Like I said ;-)

    >Actually I started on the second script months ago, but think I'll be
    >better off just scrapping that and starting fresh. It's only going to
    >be a few hundred lines anyway.


    I know what you mean. I've got a couple of script projects in the 'to
    do' list, and every once in a while run into something where I know I
    should write a script (should be pretty easy, you just ... ... and
    maybe ...) only to discover it's already on the list. Some day...

    Old guy

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