[9fans] bug in echo? - Plan9

This is a discussion on [9fans] bug in echo? - Plan9 ; On Mar 26, 2008, at 4:09 PM, andrey mirtchovski wrote: >> values of Δ will give rise to doom! > > at least get that one right, please? You don't get it, do you? Δ is the symbol for change. ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 60

Thread: [9fans] bug in echo?

  1. Re: [9fans] bug in echo?

    On Mar 26, 2008, at 4:09 PM, andrey mirtchovski wrote:

    >> values of Δ will give rise to doom!

    >
    > at least get that one right, please?



    You don't get it, do you?
    Δ is the symbol for change.
    Now do you get it?

    CHANGE ---> DOOM



  2. Re: [9fans] bug in echo?

    2008/3/26 Rob Pike :
    > echo -n -n'
    > '
    >
    > -rob
    >
    >


    I know this is a silly question, but doesn't this defeats the purpose
    of the first -n?

    iru


  3. Re: [9fans] bug in echo?

    >
    > You don't get it, do you?
    > Δ is the symbol for change.
    > Now do you get it?
    >
    > CHANGE ---> DOOM


    despite being quite the little tard, i'll give you a pass. what you
    quoted incorrectly is this:

    9grid% sed -n 88,91p /usr/andrey/unix/V6/usr/source/s2/mv.c
    if(*--argp1 == '.'){
    write(1,"values of B will give rise to dom!\n",37);
    exit();
    }
    9grid%

    description here: http://cm.bell-labs.com/cm/cs/who/dmr/odd.html

  4. Re: [9fans] bug in echo?

    Yes I know what I quoted. I changed the B to a Delta to represent
    change and turned dom to doom. YOU ARE THE TARD IF YOU DID NOT GET
    THAT. It now reads CHANGE --> DOOM!

    We need to keep echo the same because of the fact we can't agree on
    something.

    On Mar 26, 2008, at 4:30 PM, andrey mirtchovski wrote:

    >>
    >> You don't get it, do you?
    >> Δ is the symbol for change.
    >> Now do you get it?
    >>
    >> CHANGE ---> DOOM

    >
    > despite being quite the little tard, i'll give you a pass. what you
    > quoted incorrectly is this:
    >
    > 9grid% sed -n 88,91p /usr/andrey/unix/V6/usr/source/s2/mv.c
    > if(*--argp1 == '.'){
    > write(1,"values of B will give rise to dom!\n",37);
    > exit();
    > }
    > 9grid%
    >
    > description here: http://cm.bell-labs.com/cm/cs/who/dmr/odd.html




  5. Re: [9fans] bug in echo?

    On Wed, Mar 26, 2008 at 5:56 PM, Pietro Gagliardi wrote:
    > Yes I know what I quoted. I changed the B to a Delta to represent
    > change and turned dom to doom. YOU ARE THE TARD IF YOU DID NOT GET
    > THAT. It now reads CHANGE --> DOOM!
    >
    > We need to keep echo the same because of the fact we can't agree on
    > something.
    >


    what makes you think agreeing with you is of any relevance?

    iru


  6. Re: [9fans] bug in echo?

    I don't care if you agree with Bill Gates on the issue. The problem
    is that everyone has about 30 different ways of solving the problem
    and there isn't a definite solution that will cause something to
    break. Let's face it -- this is 98.438604% futile.

    On Mar 26, 2008, at 6:06 PM, Iruata Souza wrote:

    > On Wed, Mar 26, 2008 at 5:56 PM, Pietro Gagliardi
    > wrote:
    >> Yes I know what I quoted. I changed the B to a Delta to represent
    >> change and turned dom to doom. YOU ARE THE TARD IF YOU DID NOT GET
    >> THAT. It now reads CHANGE --> DOOM!
    >>
    >> We need to keep echo the same because of the fact we can't agree on
    >> something.
    >>

    >
    > what makes you think agreeing with you is of any relevance?
    >
    > iru
    >




  7. Re: [9fans] bug in echo?

    On Wed, Mar 26, 2008 at 7:26 PM, Pietro Gagliardi wrote:
    > I don't care if you agree with Bill Gates on the issue. The problem
    > is that everyone has about 30 different ways of solving the problem
    > and there isn't a definite solution that will cause something to
    > break. Let's face it -- this is 98.438604% futile.
    >


    see, even facing this percentage of futileness, you haven't bothered
    yourself to think what are you doing here.

    iru


  8. Re: [9fans] bug in echo?

    On Wed, Mar 26, 2008 at 8:43 PM, Francisco J Ballesteros wrote:
    > but
    > echo -n '-n
    > '
    > is a hack.


    yes

    so is any of the other solutions, each with its own constraints.


    > with a different implementation it might as well
    > complaint that '
    > ' is an invalid flag.


    no. This breaks unnecesarily:

    echo -a
    -a
    which is useful.

    The kind of change I was suggesting was minimal. Just solved the problem
    did not break anything else. The only thing it could have potentialy
    break was

    echo --
    which before wrote
    --

    and now writes only the newline.
    This could be easily solved by rewriting it as
    echo -- --
    and I haven't seen any instance of this in /rc/bin (I looked even
    if it was not very carefully).

    The benefits of the change are easy to see. If you write
    echo -- anything

    you know the anything is now being echoed, whatever that is.

    >
    > And in any case, the "do the same thing the same way
    > all the times" argument suggests that -- should terminate
    > option processing. doesn't it?
    >


    Yes, it is probably true that another "if" to ignore -- after the -n could
    be added. I wrote it just as an example of how little change would be
    needed. The complete change to do it "right" would be again:
    (written as an example, untried and not being overly careful)


    #include
    #include

    void
    main(int argc, char *argv[])
    {
    int nflag, argi;
    int i, len;
    char *buf, *p;

    nflag = 0;
    argi = 0;
    if(argc > 1)
    if(strcmp(argv[1], "--") == 0)
    argi++;
    else if(strcmp(argv[1], "-n") == 0){
    nflag++;
    argi++;
    if(argc > 2 && strcmp(argv[2], "--") == 0)
    argi++;
    }

    len = 1;
    for(i = 1+argi; i < argc; i++)
    len += strlen(argv[i])+1;

    buf = malloc(len);
    if(buf == 0)
    exits("no memory");

    p = buf;
    for(i = 1+argi; i < argc; i++){
    strcpy(p, argv[i]);
    p += strlen(p);
    if(i < argc-1)
    *p++ = ' ';
    }

    if(!nflag)
    *p++ = '\n';

    if(write(1, buf, p-buf) < 0)
    fprint(2, "echo: write error: %r\n");

    exits((char *)0);
    }


    --
    - curiosity sKilled the cat


  9. Re: [9fans] bug in echo?

    Equivalently (tried but not much, cleaner).

    #include
    #include

    void
    main(int argc, char *argv[])
    {
    int nflag, argi;
    int i, len;
    char *buf, *p;

    nflag = 0;
    argi = 0;
    for(i = 1; i < argc; i++){
    if(argv[i][0] != '-' )
    break;
    if (strcmp(argv[i], "--") == 0){
    argi++;
    break;
    }
    if(strcmp(argv[i], "-n") == 0){
    argi++;
    nflag++;
    }
    }


    len = 1;
    for(i = 1+argi; i < argc; i++)
    len += strlen(argv[i])+1;

    buf = malloc(len);
    if(buf == 0)
    exits("no memory");

    p = buf;
    for(i = 1+argi; i < argc; i++){
    strcpy(p, argv[i]);
    p += strlen(p);
    if(i < argc-1)
    *p++ = ' ';
    }

    if(!nflag)
    *p++ = '\n';

    if(write(1, buf, p-buf) < 0)
    fprint(2, "echo: write error: %r\n");

    exits((char *)0);
    }


    --
    - curiosity sKilled the cat


  10. Re: [9fans] bug in echo?

    On Wed, Mar 26, 2008 at 9:57 PM, Gorka Guardiola wrote:
    > (written as an example, untried and not being overly careful)
    >
    > #include



    Two echo programs, with no options, would be less code. And then we
    could all go back to complaining about the lack of OpenOffice.org and
    Java.

    --Joel


  11. Re: [9fans] bug in echo?

    Who needs OpenOffice.org Write when you have troff?

    Who needs OpenOffice.org Calc when you have CSV and awk?

    Who needs OpenOffice.org Impress (PowerPoint) when you have troff and
    either mv or Uriel's macros?

    Who needs OpenOffice.org Draw when you have 2nd edition draw in /n/
    sources/extra?

    Who needs OpenOffice.org Base when you have PQ (which I have not tried)?
    (I have been considering writing a database for Plan 9 that uses
    distributed computing and possibly 9P.)

    Who needs Java when you have Inferno and Limbo and Dis?

    On Mar 26, 2008, at 10:21 PM, Joel C. Salomon wrote:

    > On Wed, Mar 26, 2008 at 9:57 PM, Gorka Guardiola
    > wrote:
    >> (written as an example, untried and not being overly careful)
    >>
    >> #include

    >
    >
    > Two echo programs, with no options, would be less code. And then we
    > could all go back to complaining about the lack of OpenOffice.org and
    > Java.
    >
    > --Joel
    >




  12. Re: [9fans] bug in echo?

    Iruata Souza wrote:
    > On Wed, Mar 26, 2008 at 7:26 PM, Pietro Gagliardi wrote:
    >> I don't care if you agree with Bill Gates on the issue. The problem
    >> is that everyone has about 30 different ways of solving the problem
    >> and there isn't a definite solution that will cause something to
    >> break. Let's face it -- this is 98.438604% futile.
    >>

    >
    > see, even facing this percentage of futileness, you haven't bothered
    > yourself to think what are you doing here.


    This is what I love about this list. It's sooo relevant to system software.


  13. Re: [9fans] bug in echo?

    Who has nothing better to do at school?

    It's supposed to be fun!

    brucee

    On Thu, Mar 27, 2008 at 1:37 PM, Pietro Gagliardi wrote:
    > Who needs OpenOffice.org Write when you have troff?
    >
    > Who needs OpenOffice.org Calc when you have CSV and awk?
    >
    > Who needs OpenOffice.org Impress (PowerPoint) when you have troff and
    > either mv or Uriel's macros?
    >
    > Who needs OpenOffice.org Draw when you have 2nd edition draw in /n/
    > sources/extra?
    >
    > Who needs OpenOffice.org Base when you have PQ (which I have not tried)?
    > (I have been considering writing a database for Plan 9 that uses
    > distributed computing and possibly 9P.)
    >
    > Who needs Java when you have Inferno and Limbo and Dis?
    >
    >
    > On Mar 26, 2008, at 10:21 PM, Joel C. Salomon wrote:
    >
    > > On Wed, Mar 26, 2008 at 9:57 PM, Gorka Guardiola
    > > wrote:
    > >> (written as an example, untried and not being overly careful)
    > >>
    > >> #include

    > >
    > >
    > > Two echo programs, with no options, would be less code. And then we
    > > could all go back to complaining about the lack of OpenOffice.org and
    > > Java.
    > >
    > > --Joel
    > >

    >
    >
    >



  14. Re: [9fans] bug in echo?

    well the gcc list is still waiting for you ... maybe it was volatile.

    brucee

    On Thu, Mar 27, 2008 at 2:40 PM, Robert William Fuller
    wrote:
    >
    > Iruata Souza wrote:
    > > On Wed, Mar 26, 2008 at 7:26 PM, Pietro Gagliardi wrote:
    > >> I don't care if you agree with Bill Gates on the issue. The problem
    > >> is that everyone has about 30 different ways of solving the problem
    > >> and there isn't a definite solution that will cause something to
    > >> break. Let's face it -- this is 98.438604% futile.
    > >>

    > >
    > > see, even facing this percentage of futileness, you haven't bothered
    > > yourself to think what are you doing here.

    >
    > This is what I love about this list. It's sooo relevant to system software.
    >
    >



  15. Re: [9fans] bug in echo?

    > Who needs OpenOffice.org Write when you have troff?
    >
    > Who needs OpenOffice.org Calc when you have CSV and awk?
    >
    > Who needs OpenOffice.org Impress (PowerPoint) when you have troff and
    > either mv or Uriel's macros?
    >
    > Who needs OpenOffice.org Draw when you have 2nd edition draw in /n/
    > sources/extra?
    >
    > Who needs OpenOffice.org Base when you have PQ (which I have not tried)?
    > (I have been considering writing a database for Plan 9 that uses
    > distributed computing and possibly 9P.)
    >
    > Who needs Java when you have Inferno and Limbo and Dis?
    >
    > On Mar 26, 2008, at 10:21 PM, Joel C. Salomon wrote:
    >
    >> On Wed, Mar 26, 2008 at 9:57 PM, Gorka Guardiola
    >> wrote:
    >>> (written as an example, untried and not being overly careful)
    >>>
    >>> #include

    >>
    >>
    >> Two echo programs, with no options, would be less code. And then we
    >> could all go back to complaining about the lack of OpenOffice.org and
    >> Java.
    >>
    >> --Joel
    >>


    Pietro, as usual you have missed the important part--in this case, the
    humor. I'm pretty sure Joel knows all those things you've listed
    better than you do yourself.

    Your replacements are pretty questionable, too.

    Write is basically crap. I gnash my teeth with a great anger every
    time I use it; my roommate was rather concerned a few years ago when
    OO dumped about a half hour's hard work on a lab report and I punched
    my bedframe as hard as possible... I think he feared for his life, OO
    made me that angry. However, having done basic things like format
    text, add images, and insert tables in both Write and troff, Write is
    much simpler, although I think troff does a better job. I could
    actually consider replacing Write with troff or maybe TeX if it comes
    down to it.

    CSV and awk? I like awk, and CSV is fine, but if I could choose one
    program to have on Plan 9, a decent spreadsheet would be pretty high
    up on the list; it's the original Killer App and quite convenient for
    a lot of quick, simple tasks that become less quick and simple when
    you do them almost any other way.

    While I dislike PowerPoint and think that people could do well to use
    fewer slides, we're stuck with them for now; strangely, when you're
    collaborating on a project, others aren't always thrilled when you
    tell them they need to learn a typesetting language before working on
    the slideshow. The number of .ppt files I've been mailed over the
    last couple years... pretty steep.

    Comparing Draw to the 2nd edition 'art' is rather silly. I don't
    think I need to go deeper.

    I haven't used PQ either. In fact, has anyone used PQ in the last
    couple years? I wouldn't trust OO to do my databases, but considering
    the Sinkhole of Support I'd be likely to experience with PQ (it's in
    sources/extra, it's old, it's unsupported), I'd be more inclined to
    write an interface to a remote postgresql or MySQL server, or try to
    port one of those.

    I agree with you 100% on the last point, though. Nobody needs Java,
    and nobody knows that better than the people on this list.


    John



  16. Re: [9fans] databases

    > I haven't used PQ either. In fact, has anyone used PQ in the last
    > couple years? I wouldn't trust OO to do my databases, but considering
    > the Sinkhole of Support I'd be likely to experience with PQ (it's in
    > sources/extra, it's old, it's unsupported), I'd be more inclined to
    > write an interface to a remote postgresql or MySQL server, or try to
    > port one of those.


    while databases aren't in the unix/plan 9 cannon, i've had jobs
    where we really did have a database of users, groups, subscriptions,
    searches, documents, document collections and collection groups.
    foreign keys a go go. (mysql need not apply.)

    on a small scale, this is plenty managable in a traditional filesystem.
    when you need to track ~30 million documents and a couple hundred
    million searches while insert rows in multiple tables transactionally,
    a real database is awful nice.

    while it would be nice to have a beefy plan 9 database, i wouldn't
    bother porting one even if i needed it. why not figure out what the
    client protocol is and implement that for plan 9?

    - erik



  17. Re: [9fans] databases

    I had been thinking of adding a database to Plan 9 for a while.
    Here's my design:

    The DBMS is a 9P server. Upon mounting, it takes as arguments two files:
    - the list of names of records and fields
    - the data itself
    It then parses the data into virtual files in the location given with
    the mount command.

    For example, let's say I have a customer database for a kitchenware
    distributor stored in two files: customer_fields (the list of field
    and record names) and customer_data. I can load it with:

    9dbms
    mount /srv/9dbms /n/customers customer_fields customer_data

    If that's not possible, these two filenames are stored in another file.

    Now here's what this /n/customers will have. If the fields file looks
    like this:

    !record:uvlong # records are numbered
    name:string * 1
    address:string * 2
    phoneno:string[10]
    wants:list of string

    and we have customers numbered 4, 9, and 30:

    cpu% cd /n/database
    cpu% ls
    4
    9
    30
    cpu% ls 4
    name
    address
    phoneno
    wants
    cpu% cat 4/wants
    3 of 30-inch deep pots
    4 sets of 20 Imperial-grade steel forks
    cpu%

    You see what's going on? The use of 9P means there will be NO special
    API for accessing the database: you just use open, read, write, &c,
    or rc and the standard tools. This makes report generation a breeze:

    #!/bin/rc
    rfork e
    cd /n/database
    {
    echo '.DS'
    for(i in *){
    cat $i/name
    cat $i/address
    cat $i/phoneno
    echo 'REQUESTS:
    cat $i/wants
    echo
    }
    echo '.DE'
    } | troff -ms

    Or, for a more elaborate report:

    #!/bin/rc
    rfork e
    cd /n/database
    {
    cat <<\END
    .TS
    center;
    c s
    lfB lfB lfB lfB
    l l l l.
    \fBREPORT\fP
    Name Address Phone Number Wants
    END
    for(i in *){
    cd $i
    name=`{cat name}
    addr=`{cat address}
    pn=`{cat phoneno}
    echo $"name^' '^$"addr^' '^$"pn^' T{'
    cat wants
    echo 'T}'
    cd ..
    }
    } | tbl | troff -ms

    Then, if you use bitsy, you can write a program with libcontrol and
    the networking commands to make a portable remote customer editor!



  18. Re: [9fans] bug in echo?

    // I haven't used PQ either. In fact, has anyone used PQ in the
    // last couple years?

    Yes. In the past few years I've worked with teams building two
    unrelated applications with it. One went through a technology
    trial with a Tier 1 US telecom provider, but then floundered for
    unrelated reasons. The other was, for years, responsible for
    moving several millions of dollars around every month between
    a few hundred global GSM operators. The company has since
    been sold; the buying company initially decided on using our
    platform to replace theirs, but then everyone I knew there left,
    so I can't comment on current state. The web site for the
    service is at least unchanged.

    Sadly, both those projects relied on an update mechanism which
    was a proprietary extention not included in the distribution.
    Getting a good update mechanism that fits well with the
    distrubuted version has been an ongoing challenge.

    The official directory folks at ALU were, at least until shortly
    after the merger, using it as a front end for an assortment of
    proprietary HR-type systems. I believe that was dying out,
    although I can't say as the folks I knew there have since gone
    over to at&t. That group's version was an evolutionary cousin
    of the Plan 9 one.

    I'm also using it on a personal project, and am working on
    updating the distrubution, in part in response to second-hand
    requests from some folks who want to update an application
    using (almost exactly) the Plan 9 version on Solaris.

    So, yes. It's probably a single-digit number of active projects
    and double-digit user base (not counting users of the services
    these applications provide, in which case it's at least single-
    digit thousands), but non-zero.
    Anthony



  19. Re: [9fans] databases

    We've spent a lot of time thinking about file system front ends
    for databases (mostly in the context of pq, but not entirely). I'm
    unconvinced that this model of representation really adds much
    for most databases.

    The problem is that the application talking to the database
    still has to know too much about the representation, making it
    fairly static. This isn't inherently a problem, really, but it isn't
    anything resembling a relational (or, since pq was mentioned,
    implicit relational) database.

    One could certainly do an on-the-fly generated namespace in
    response to each query. That'd be neat for interactive use, but,
    again, any real application using it would have to already know
    a lot about the structure of what it's getting back. Given that,
    getting the database out of a file tree isn't really a win over
    getting it out of a tab-separated text line (or whatever your
    DB gives you).

    Two related things I think *are* more interesting. First, I've
    often found it useful to have a "middleman" application
    turning a more general backing store into a more structured
    file tree. This is, for example, how Inferno's styx-on-a-brick
    demo worked: each layer in the stack provided a different
    file tree with more structure imposed (okay, it was a short
    stack). This allows you to avoid stuffing too many of the
    specifics into what should be more general.

    Second, and really more simply, we've found it useful to
    have a channel to the database present in the file system.
    Eliminate any network programming from your apps, and if
    the app providing the channel does a good job, you get a set
    of benifits more or less for free (or at least for aggregated cost).
    Anthony



  20. Re: [9fans] bug in echo?

    "Gorka Guardiola" wrote in message
    news:599f06db0803260640s15d37727q2f619f1a3c86dc47@ mail.gmail.com...
    > The fix doesn't break anything, ...


    Any change in externally visible behavior could in principle
    "break something" that had relied on the previous behavior.

    That said, "echo" has historically been a problem since
    without support for option arguments it is too limited,
    but with support for option arguments one has to worry
    about accidental options, as in the original question. With
    incomplete support for option arguments it is just confusing.

    I got disgusted enough with the variety among versions of
    "echo" that impacted upon otherwise portable shell scripts
    that I designed my own version that supports the Unix
    command syntax standard, is flexible enough to provide
    all the useful option behavior modifications (including
    optionally enabling embedded \-escapes), and can be
    "aliased" to any of the usual flavors of "echo" by including
    thright combination of options in the prefix. I named it
    "gecho" (for "generic", not "GNU") and can provide specs
    and/or implementation upon request.

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast