Professional Web Applications Themes

Living with "Repair Permissions" nonsense - Mac Applications & Software

Tom Harrington <no.spam.dammit.net> writes:    > > Have I ever considered switching to _what_ shell?[/ref] I suspect he means zsh. A couple of us recommended that he look at that - and the _excellent_ online doentation that exists for it. Of course, it won't do him one iota of good with respect to dd or pdisk or anything else that's not a shell built-in. -- Plain Bread alone for e-mail, thanks. The rest gets trashed. No HTML in E-Mail! -- http://www.expita.com/nomime.html Are you posting responses that are easy for others to follow? http://www.greenend.org.uk/rjk/2000/06/14/quoting...

  1. #201

    Default Re: Living with "Repair Permissions" nonsense

    Tom Harrington <no.spam.dammit.net> writes: 
     
    >
    > Have I ever considered switching to _what_ shell?[/ref]

    I suspect he means zsh. A couple of us recommended that
    he look at that - and the _excellent_ online doentation
    that exists for it.

    Of course, it won't do him one iota of good with respect to dd
    or pdisk or anything else that's not a shell built-in.




    --
    Plain Bread alone for e-mail, thanks. The rest gets trashed.
    No HTML in E-Mail! -- http://www.expita.com/nomime.html
    Are you posting responses that are easy for others to follow?
    http://www.greenend.org.uk/rjk/2000/06/14/quoting
    BreadWithSpam@fractious.net Guest

  2. #202

    Default Re: Living with "Repair Permissions" nonsense

    In article <221020030346278295%com>,
    Mark Conrad <com> wrote:

     

    I think this thread is going in circles.

    Unless your man page is different than mine, I must ask just what, pray
    tell is wrong with the man page for 'ls'? It does explain what every
    option does. How many paragraphs of description do you need to
    understand that the -t option sorts by time modified.

    Which option is not doented in the man page that you think should be?

    And remember, the man page for 'ls' (or other commands) are _not_
    intended to be unix training manuals. They explain what the command
    does, not how unix works. I don't expect the one page 'manual' that
    came with my torque wrench to go beyond the wrench itself - I don't
    expect to get a 3000 page book teaching me how to be a mechanic. The
    wrench is a tool and the writer of the manual expects me to know what it
    is for and how and when to use it, just as the writer of the 'ls' man
    page tells how to use the 'ls' tool to see the 'sticky bit', it is
    expected the user of the tool knows what a sticky bit is and why he
    might want to view it.

    --
    -Ernie-

    "There are only two kinds of computer users -- those who have
    suffered a catastrophic hard drive failure, and those who will."

    Have you done your backup today?
    Ernie Guest

  3. #203

    Default Re: Living with "Repair Permissions" nonsense

    On Wed, 22 Oct 2003 15:57:34 -0700, Ernie Klein <net> wrote: 
    >
    > I think this thread is going in circles.[/ref]

    Threads with Mark tend to do that. I think he's doing this
    intentionally; it's the most logical explaination.

    Dave Guest

  4. #204

    Default Re: Living with "Repair Permissions" nonsense

    While we're rippin' up man pages ;-)
    I'm alongside the OP here

    from today's chores:

    man 8 route
    ....
    DESCRIPTION
    Route is a utility used to manually manipulate the network
    routing tables. It normally is not needed, as a system routing
    table management daemon such as routed(8), should tend to this task.
    ....

    BUGS
    The first paragraph may have slightly exaggerated routed(8)'s
    abilities.

    4.4BSD June 8, 2001 4.4BSD

    umm yeah, considering routed doesn't normally run in OS X

    man 4 route
    ....
    DESCRIPTION
    Mac OS X provides some packet routing facilities. The kernel
    maintains a routing information database, which is used in
    selecting the appropriate network interface when transmitting
    packets.
    ....

    BSD April 19, 1994 BSD

    eh? Mac OS X didn't exist in 1994

    man routed
    ....
    DESCRIPTION
    Routed is a daemon invoked at boot time to manage the network
    routing tables. It uses Routing Information Protocol, RIPv1
    (RFC 1058), RIPv2 (RFC 1723), and Internet Router Discovery
    Protocol (RFC 1256) to maintain the kernel routing table. The
    RIPv1 protocol is based on the reference 4.3BSD daemon.

    again, not on this flavor of BSD
    it's the circular references, and the recursive effects of undoented
    features, makes you want to read between the lines, but there's nothing
    there....
    Peter Guest

  5. #205

    Default Re: Living with "Repair Permissions" nonsense

    On Thu, 23 Oct 2003 17:54:59 +1300, Peter KERR <domain> wrote: 

    So you'd rather they only include the man pages that are for installed
    daemons that run by default?
     

    Um. OS X is built on FreeBSD, which has it's roots in the 1980's.
    Surely you aren't saying that they should rewrite all of the man pages
    every time someone does a distribution of FreeBSD?
     

    Great - it's open source, and the FreeBSD organization would, I'm sure,
    welcome someone volunteering to fix a perceived problem. Are you
    volunteering, then?

    Man pages aren't perfect. But complaining about them on the basis of
    the label, or that it doesn't run by default, is pointless.

    Dave Guest

  6. #206

    Default Re: Living with "Repair Permissions" nonsense

    In article <tph-F01B1B.14063222102003localhost>, Tom Harrington
    <no.spam.dammit.net> wrote:
     
    >
    > Yowza. OK, 600 commands, which by your estimate works out to 9000
    > pages. And you want this for free? You're mighty generous with other
    > people's time.[/ref]

    No, I never said anything about dispensing this for free, you are
    reading that into it yourself.

    What I wrote was:

    "...a free downloadable book showing SAMPLE USAGE..."

    A sample is far from being the actual thing, in case that is not
    obvious to you.

    For example, one could describe in plain text the _sample_ _usage_
    of the dd command which allows someoneone to quickly create a bootable
    backup of their OS X partition, a backup that has advantages over other
    more conventional backup schemes, and list those advantages.

    That description is a far cry from showing the actual details of how to
    use dd to accomplish the backup and subsequent restore of an OSX
    partition.

    One could describe in plain text the non-obvious benefits of using
    commands like pdisk. For example, pdisk allows one to determine the
    relative position of one's OS X partition on disk.

    For example, my OSX partition is #9, even though it is the first user
    partition on my disk, which has only five partitions that I created
    using Disk Utility.

    This information is critical in getting some other commands like dd to
    work properly.




    If one stated that he/she was offering easy-to-follow instructions
    about how to use 600 commands, then one would like to be paid in some
    form for going to all this time and trouble - - - the same as the
    author of a book gets paid for writing a book.

    Now all the above in no way prevents one from offering a _free_
    helping hand to others regarding actual real-life usage of these
    commands, *if* they are inclined to do so in these newsgroups.


     
    >
    > Have I ever considered switching to _what_ shell?[/ref]

    I don't know. I read somewhere that there was a shell that was a
    superset of the bash shell, but I can't locate that reference now.

    Mark-
    Mark Guest

  7. #207

    Default Re: Living with "Repair Permissions" nonsense

    In article <newsguy.com>,
    Ernie Klein <net> wrote:
     

    I thought you would never ask ;-)

    Nothing is wrong with the man page for ls, provided you are a Unix whiz
    and know all the terms the man pages use.

    "If more than one operand is given, non-directory operands are
    displayed first; directory and non-directory operands are sorted
    seperately and in lexicographical order."

    None of that confusing gibberish is in the good 15 page explanation of
    "ls" in the book "Learn Unix in 24 Hours".

    Just for beginners, is a Mac guy trying to learn "ls" supposed to know
    what an "operand" is?

    What is the difference between "directory and non-directory operands".

    Can we count on a Mac user knowing what "lexicographical order" means.

     

    In this case a more simple and concise explanation of the -t option
    goes a lot further in explaining it than the confusing nan page does.

    The book description of the -t option:
    "Sort output in most recently modified order."

    The man page description of the -t option:
    "Sort by time modified (most recently modified first) before sorting
    the operands by lexicographical order."


    Now which of the above descriptions of the -t option do you think would
    make more sense to a person trying to learn how to use "ls".

     

    Precisely, so we are left stranded without a training manual, aren't we.

    Mark-
    Mark Guest

  8. #208

    Default Re: Living with "Repair Permissions" nonsense

    In article <panix.com>,
    <net> wrote:
     
    >
    > dd and pdisk are simply commands. They are not shell-specific
    > nor are they shell built-ins. There won't be a single word
    > about them in a book about the shell. They will be doented
    > independently.[/ref]

    I know, and that is a crying shame. The shell is essentially useless
    unless the commands are known.

    Simple logic would dictate if I were writing a book about a shell, that
    I should include chapters about the commands that can be used with the
    shell, and where to find a good tutorial describing more about those
    commands.

     

    Where? - - - several here have said there is no such thing as a
    _tutorial_ on commands like dd and pdisk.

    Mark-
    Mark Guest

  9. #209

    Default Re: Living with "Repair Permissions" nonsense

    Mark Conrad <com> writes: 
    > >
    > > dd and pdisk are simply commands. They are not shell-specific
    > > nor are they shell built-ins. There won't be a single word
    > > about them in a book about the shell. They will be doented
    > > independently.[/ref]
    >
    > I know, and that is a crying shame. The shell is essentially useless
    > unless the commands are known.[/ref]

    It's not a shame in the slightest. dd is an entirely independent
    program from the shell and the shell built-ins. One could have
    dd without having the shell, and one could have the shell without
    having dd.

    You seem to really be fighting the notion that the shell and
    the other programs that one might use from the shell are different.
    They are.
     

    Perhaps if you were writing a book about a particular distribution
    of a unix-like system and knew that that particular system included
    both a particular shell and certain other specific programs, then
    including chapters about both the shell and those other programs
    might make sense.

    But there's no reason whatsoever for the doentation for the
    shell to say one word about, say, dd or pdisk.

    You complain when folks correct the the names by which various
    things in the operating system are called. "shell commands"
    for example, is a fuzzy term. "cd" is a "shell built-in" -
    it's a function which the shell itself actually does for you.
    "dd" and "pdisk" are _not_ "shell built-in" commands. They
    are entirely independent programs, just as emacs or grep or,
    say, Microsoft Word are.

    Should the shell doentation explain MS Word for you, too?

    No. independent programs are doented independently.
     

    So write that book.
     
    >
    > Where? - - - several here have said there is no such thing as a
    > _tutorial_ on commands like dd and pdisk.[/ref]

    There is no tutorial.

    The doentation is right there at your command line.

    man dd

    man pdisk

    If those docs aren't any good (and you're knowledgeable enough
    to really make that judgement), feel free to write up better
    docs and a tutorial. Those docs seem to be perfectly adequate
    for the folks for whom it's appropriate that they be using these
    programs.

    The overwhelming majority of mac users have no need for these
    things, by the way. The OS was designed so that end users never
    need go near this stuff at all. This wasn't _meant_ to be easy.
    If you can't read and understand the man pages, don't use these
    commands until you do, get a point-and-click equivalent, or ask
    for help nicely (and _listen_ to what the knowledgeable folks
    tell you instead of arguing that it shouldn't be this way).



    --
    Plain Bread alone for e-mail, thanks. The rest gets trashed.
    No HTML in E-Mail! -- http://www.expita.com/nomime.html
    Are you posting responses that are easy for others to follow?
    http://www.greenend.org.uk/rjk/2000/06/14/quoting
    BreadWithSpam@fractious.net Guest

  10. #210

    Default Re: Living with "Repair Permissions" nonsense

    In article <231020030620372479%com>,
    Mark Conrad <com> wrote:
     

    Didn't we do this one already? Most Mac users have no reason to care
    what the man pages say. They'll never read them or miss doing so, so
    the question of whether they'd understand them is completely irrelevant.

    --
    Tom "Tom" Harrington
    Macaroni, Automated System Maintenance for Mac OS X.
    Version 1.4: Best cleanup yet, gets files other tools miss.
    See http://www.atomicbird.com/
    Tom Guest

  11. #211

    Default Re: Living with "Repair Permissions" nonsense

    In article <tph-C9D324.11065423102003localhost>, Tom Harrington
    <no.spam.dammit.net> wrote:
     
    >
    > Didn't we do this one already? Most Mac users have no reason to care
    > what the man pages say. They'll never read them or miss doing so, so
    > the question of whether they'd understand them is completely irrelevant.[/ref]

    The terms all mean the same thing they've meant for the last thirty
    years or so. If you're thirty years behind on your computer knowledge,
    well, that is regrettable, but it's not Unix's fault. Unix doesn't
    seek out users; users seek out Unix.

    Learning thirty years' worth of trivial details is never going to be an
    easy task no matter what you're studying. If you need serious Unix
    expertise now, simply start learning ten years ago.

    --
    Jerry Kindall, Seattle, WA <http://www.jerrykindall.com/>

    Send only plain text messages under 32K to the Reply-To address.
    This mailbox is filtered aggressively to thwart spam and viruses.
    Jerry Guest

  12. #212

    Default Re: Living with "Repair Permissions" nonsense

    In article <231020030639159714%com>,
    Mark Conrad <com> wrote:
     
    > >
    > > dd and pdisk are simply commands. They are not shell-specific
    > > nor are they shell built-ins. There won't be a single word
    > > about them in a book about the shell. They will be doented
    > > independently.[/ref]
    >
    > I know, and that is a crying shame. The shell is essentially useless
    > unless the commands are known.[/ref]

    That is remarkably silly, or pig-headed. The entire function of a
    "shell" is to provide direct user interaction with _whatever_ the
    system has available to run. In that sense, the Finder is a "shell"
    also. Do you think that a tutorial on the Mac Finder should include
    doentation of all the programs that are run from it? Why, for
    God's sake?

    A shell is a user interface. Period. What it interfaces to must be
    doented otherwise -- in the classic UNIX manner, via man pages or
    (for starters) overview docs that introduce _some_ of the available
    commands without being exhaustive even about the commands described,
    but mean to introduce basic idioms and style in using a system. All
    of this is avaialable in many different forms for UNIX in general and
    the Mac OS in particular.

    All of this has been pointed out to you _many_ times, and you continue
    to want the system to magically adapt to YOUR MISCONCEPTIONS, instead
    of trying to handle the (really very simple) conceptions that are in
    fact at the base of the system.
     

    Your "simple logic" would turn the brief doentation of a quite
    simple (and very elegant) User Interface program into a massive tome
    explaining in gory detail every conceivable thing in the system --
    needing major updates with every system release, instead of being
    a basically very simple and stable guide to _how_ one executes _any_
    available commands from the "CLI". 
    >
    > Where? - - - several here have said there is no such thing as a
    > _tutorial_ on commands like dd and pdisk.[/ref]

    Man pages, idiot. If you can't read them, you are confessing to
    ignorance that _should_ warn you that you are out of your depth in
    _trying_ to use dd or pdisk. That ignorance _could_ be redressed --
    but not when you insist that you _will_ not do what others recommend
    to you to redress it.

    Everyday use of the Mac (or any UNIX) has little or no need of man
    page detail and specifics, and simple things that you might want to
    do from a shell have correspondingly simple man pages that may be a
    bit cryptic if you haven't been exposed to this before (and that _is_
    what tutorials on the UNIX side of Mac OSX are about). As a general
    rule, if YOU don't understand a man page, YOU have no business using
    the command. Period.

    If this sounds "elitist", tough. It is _your_ problem, because you
    insist on trying to tinker with low level guts of a system that you
    refuse to take the time and effort to understand. You _deserve_ to
    get yourself into trouble.
    Michael Guest

  13. #213

    Default Re: Living with "Repair Permissions" nonsense

    On Tue, 21 Oct 2003, Mark Conrad wrote: 
    >
    > Uh, yeah, right.
    >
    > That would be something like my general-practitioner doctor saying to
    > me, "Don't worry if you need brain surgery, I will learn how to do it
    > if the occasion arises." ;-)
    >[/ref]

    I won't try to correct the ogy -- I don't think it's quite right --
    I agree with the remark you're responding to, or there is a way of
    interpreting it that I agree with, at least.

    The amount to learn is far to great to try to learn it all and then do
    something. What I think might be a good goal is to learn the basic
    behavior of many commands, have some idea of what options exist for
    them, and focus on how to combine them to do great things. The latter
    part is what shell programming is all about. If one procedes in that
    fashion, one will discover the meaning of the Spamster's remark that I
    hold.

    Here's a webized version of a fundamental memo on the unix shell. If
    you focus on this relatively short memo, you'll be well started on the
    way to where you want to get.

    <http://rhols66.adsl.netsonic.fi/era/unix/shell.html>

    joe
    Joe Guest

  14. #214

    Default Re: Living with "Repair Permissions" nonsense

    On Tue, 21 Oct 2003, Mark Conrad wrote: 
    >
    > You mentioned that Amazon had some sample pages online, about the
    > various shell books they sell. I did not follow up and look at the
    > sample pages, for two reasons:
    >[/ref]

    No, actually, I did NOT merely suggest they had sample pages about the
    various shell books they sell. I pointed to a PARTICULAR book and
    PARTICULAR sample pages and recommended that you look at THOSE sample
    pages to see if they were what you were looking for. I stand by that
    recommendation -- that 1 book and those particular sample pages.
     

    No, actually, the shell is a separate command; it has arguments of it's
    own, but the arguments to ls belong to ls, not the shell. There are
    different versions of ls out there, but those versions are independent
    of what shell you use. Your statement is like "some forks have
    different kinds of flour in their spaghetti". Different versions of
    spaghetti are made from different kinds of flour, but they're all
    independent of the fork -- one uses a fork to manipulate spaghetti,
    whichever kind it is, and whichever fork on uses. ls is a
    program. Different versions have different arguments.
    sh/zsh/bash/csh/tcsh/ are all shells. They listen to keyboards and call
    other programs. One uses a shell to invoke some version of ls.
    It is true that many shells have some commands builtin, "cd" is a common
    one -- but ls usually is not -- it's too complex.

    You used MS/DOS, neh? Command.com is the shell there, or once was.
    Aint' much it can do by itself, but ain't much you can do without it.
    Unix shells are, in general, significantly fancier, but still can't do
    much without other programs.

    Don't want to seem too pedantic, but, as with lisp, it's important to
    properly identify the components to learn it. Understanding eval is a
    key to understanding lisp. The shell simply provides the
    read-eval-print loop for unix -- but the syntax is more complex.

    joe
    Joe Guest

  15. #215

    Default Re: Living with "Repair Permissions" nonsense

    On Thu, 23 Oct 2003, Mark Conrad wrote: 
    > >
    > > dd and pdisk are simply commands. They are not shell-specific
    > > nor are they shell built-ins. There won't be a single word
    > > about them in a book about the shell. They will be doented
    > > independently.[/ref]
    >
    > I know, and that is a crying shame. The shell is essentially useless
    > unless the commands are known.
    >[/ref]


    But Mark -- when I go to my Lisp manual and read the description of
    eval, it doesn't tell me about equal -- and I'd consider it a misfeature
    if it did.

    Sure, the Mac is the computer "for the rest of us", so we expect more
    tutorial material and ease of use than from Unix, which is "for the geeks".
    But Apple cleverly hid the Terminal application away from the rest of
    us. One of the finest things they've done is put unix underneath the mac
    os so the rest of us don't really need to know about it.

    Granted, Lotus 1-2-3 did a great job of making it both novice and expert
    friendly. Perhaps one day, after people like you've beaten their heads
    against it long enough, we'll get the tutorials needed -- but they'll
    have to be written by people like you. Danny Goodman would be the guy
    to write the book you need -- you should suggest it. Even as a unix
    geek, I found his Hypercard handbook worth reading. It was impressive
    to see someone who wasn't a programmer find amazingly useful things that
    could be done with Hypercard and take the time to teach it to others. I
    hope he got rich off it.

    However, once you slip past Apple's attempts to conceal, and look into
    the Utilities folder, you're treading on dangerous ground.

    When you put on your green trowsers and step behind that curtain
    you're expected to be a wizard -- you're not in Kansas anymore, so
    Kansas law doesn't apply.

    It occurs to me to that the sorcerer's apprentice may have found the
    manpage for the broom was too hard to understand, too.

    joe



    Joe Guest

  16. #216

    Default Re: Living with "Repair Permissions" nonsense

    In article <231020030620372479%com>,
    Mark Conrad <com> wrote:
     
    I don't know. How is a Mac guy supposed to know _anything_ computer
    related? 'operand' is a term, not exclusive to Unix, that has a long
    history of being used in describing computer operations, meaning the
    value being operated on. From the Synopsis and Description of the man
    page for 'ls' it should be obvious to (almost) anyone who is not being
    deliberately obtuse, even without knowing what the word means.
     

    DESCRIPTION
    For each operand that names a file of a type other than directory,
    ls displays its name as well as any requested, associated information.
    For each operand that names a file of type directory,

    Seems rather clear - one is a file, the other is a directory (they are
    both types of files however) 

    A Mac user doesn't need to know, unless he want to know the proper
    computer science name for the order in which ls sorts it's output. Did
    your 'simple to read' book explain "lexicographical order", or did it
    mention it at all? If it skipped over it, then your book didn't
    accurately describe the command, because the man page is precise in it's
    description:

     

    I agree, it's simpler. Any time you leave out important details it
    makes thing simpler.

    What does the 'book' say about the output order when several (hundred)
    all have the _same_ modify time? Hint - they are sorted in
    lexicographical order.
     
    The 'book' might be simpler, but the man page is correct. 
    The correct one, if he want to know what the command actually does.
     
    >
    > Precisely, so we are left stranded without a training manual, aren't we.[/ref]

    There are many, but they are not man pages. You have been referred to
    all kinds of good reference material which I will not repeat here.

    --
    -Ernie-

    "There are only two kinds of computer users -- those who have
    suffered a catastrophic hard drive failure, and those who will."

    Have you done your backup today?
    Ernie Guest

  17. #217

    Default Re: Living with "Repair Permissions" nonsense

    In article <client.attbi.com>, Joe Davison
    <net> wrote: ...about comparisons to Lisp...
     
    > >
    > > I know, and that is a crying shame. The shell is essentially useless
    > > unless the commands are known.
    > >[/ref]
    >
    >
    > But Mark -- when I go to my Lisp manual and read the description of
    > eval, it doesn't tell me about equal -- and I'd consider it a misfeature
    > if it did.[/ref]

    I humbly disagree that it would be a misfeature.

    Part of the eval _definition_ should be about how it, er,
    _evaluates_ whether something is "equal", and just _how_ equal.

    There are at least four ways of determining equality in Lisp.

    They are the terms "eq", "eql", "equal", "=". Furthermore, "equal"
    has modifier terms that change its meaning slightly.

    To add to this complexity about the definition of eval and how that
    definition relates to equal, one would _also_ have to understand
    macros, closures, generators, continuations, and other state-preserving
    constructs in Lisp, because they all have an effect on equality, and
    therefore have an effect on the definition of "eval" and how "eval"
    evaluates whether something is "equal" or not.

    A robust proper definition of eval should include all of the above,
    plus possibly other things like how the compiler's possible use of
    "user created" compiler macros might modify the meaning of the Lisp
    source code, and therefore affect the definition of eval, ... and also
    possibly how Lisp's unique ability to use Lisp source code to create
    other Lisp source code on the fly would affect the definition of
    "eval", as it relates to determining how "eval" handles evaluating
    equality or the lack of equality.

    Keep in mind that modern Lisps are partly interpreted, and partly
    compiled, by default. Kinda like "interpret a little", then "compile a
    little", as the Lisp program runs.

    ....so it is rare to see an entirely interpreted Lisp nowadays. The
    fact that a compiler enters the picture when "eval" is (normally) used,
    complicates how to define "eval".

    Mark-
    Mark Guest

  18. #218

    Default Re: Living with "Repair Permissions" nonsense

    In article <client.attbi.com>, Joe Davison
    <net> wrote: ...a useful and stimulating post...

    Gadd this is fun, different points of view from different people, this
    is what these newsgroups are all about :)

    Cross-fertilization is rampant, and that is good.

    I have _my_ viewpoint, others have theirs.

    Chances are that I will not change my viewpoint, nor will others change
    their viewpoints. We can all argue 'til the cows come home, but in
    the end what have we accomplished. Nothing.

    Time to take inventory of this situation, and faithfully define the
    _differences_ between the two viewpoints, without resorting to
    ridicule or distortion or any other negative descriptions of "the other
    guy's" viewpoint about how the cookie crumbles.

    Remember, these are _differences_ , the Majority viewpoint will be
    given first, followed by the Unpopular viewpoint. M) and U)

    M) People should not complain about the lack of simple-to-understand
    tutorials, that is a fact that we have to live with.
    U) People should complain, and furthermore they should do something to
    remedy the lack of tutorials.

    M) The man pages are adequate for learning commands.
    U) The man pages are confusing, were never intended to be a tutorial.

    M) There is a big difference between learning builtin commands like
    "cd" versus learning external commands like "dd"
    U) No difference to speak of. If a Mac user did not know how to use
    the builtin command "cd", he certainly could not find out how to use it
    by typing "man cd" and reading what was displayed.

    M) People trying to learn commands by their own methods should be
    beaten down, ridiculed, called names, and forced into the standard Unix
    mold.
    U) People trying to learn commands by _any_ method should be
    encouraged to do so, if it becomes apparent that they are fixed in
    their ways.

    M) If one does not understand the man pages, one has no business
    trying to use the commands.
    U) If one does not understand the man pages, one can still use the
    commands to good advantage.

    M) The definition of Unix terminology is written in stone, and means
    the same thing to everyone trying to learn the "commands".
    U) The words used in Unix books vary, some use "commands", some use
    other terms like "utilities" or "programs" or "tools" or
    "applications".
    For the things that change what a "command" does, some call them
    "arguments" or "flags" or "options".
    It is much more important to define the meaning one attaches to a
    technical word, rather than rely on the student having an understanding
    of a "standard" Unix technical term.



    I have probably missed some other differences in viewpoints, and I
    probably have been guilty of some bias when writing all the above
    supposedly "unbiased" viewpoints.

    FWIW, your excellent posts stand out from others, and are much more
    liable to influence me in a positive manner, than other posts from
    abusive people in this NG.
    Mark Guest

  19. #219

    Default Re: Living with "Repair Permissions" nonsense

    In article <client.attbi.com>, Joe Davison
    <net> wrote:
     
    >
    > No, actually, I did NOT merely suggest they had sample pages about the
    > various shell books they sell. I pointed to a PARTICULAR book and
    > PARTICULAR sample pages and recommended that you look at THOSE sample
    > pages to see if they were what you were looking for. I stand by that
    > recommendation -- that 1 book and those particular sample pages.[/ref]

    I am embarassed to say that I lost track of that particular post.

    I will check the back posts using that service that archives old posts,
    I think it is Alta-Vista or Deja-News or something like that - - - I
    will have to check my books to be certain.

    Will get back to you later with my conclusion as to whether the book
    you recommended is the kind of tutorial book I am looking for.

    Mark-
    Mark Guest

  20. #220

    Default Re: Living with "Repair Permissions" nonsense

    In article <bn8gh5$u6k0e$news.uni-berlin.de>,
    Dave Hinz <net> wrote: 
    >
    > So you'd rather they only include the man pages that are for installed
    > daemons that run by default?[/ref]

    No, but some editing might be in order, see below
     
    >
    > Um. OS X is built on FreeBSD, which has it's roots in the 1980's.
    > Surely you aren't saying that they should rewrite all of the man pages
    > every time someone does a distribution of FreeBSD?[/ref]

    Not -all_ of the man pages for a FreeBSD distro, but my post showed
    somebody had added
    Mac OS X provides some packet routing facilities.
    to that page. The tidy housekeeping thing is to update at least the
    version or modification date.
     
    >
    > Great - it's open source, and the FreeBSD organization would, I'm sure,
    > welcome someone volunteering to fix a perceived problem. Are you
    > volunteering, then?[/ref]

    Last time I volunteered, and offered an updated ReadMe for the Darwin
    Install, it fell into a crack, because the installer and procedures all
    changed in the next version...
     

    Whose complaining? Not me ;-)
    I'm just pointing out, that like some other well known household books,
    man pages can't always be taken at face value...
    Peter Guest

Page 11 of 11 FirstFirst ... 91011

Similar Threads

  1. "Contribute changes file permissions" Tech Note tn_19176
    By John Waller in forum Macromedia Contribute General Discussion
    Replies: 0
    Last Post: May 26th, 09:48 AM
  2. NTFS Permissions & "Failed to Start Monitoring File Changes"
    By Alex Maghen in forum ASP.NET Security
    Replies: 0
    Last Post: February 3rd, 02:21 AM
  3. Weird Permissions Thing (rw-r--r--, but vi says "read only")
    By Weston C in forum Mac Applications & Software
    Replies: 1
    Last Post: July 8th, 10:55 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139