1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Enhanced TYPE command

Discussion in 'Suggestions' started by Steve Fabian, Sep 15, 2010.

  1. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Two independent enhancements are suggested for the TYPE command, useful only
    if output is piped or redirected:

    1/ Unicode/ASCII selection option
    This option would force output mode regardless of the current state of
    the UnicodeOutput directive; it might also include specifying codepage.

    2/ EOL selection option
    This option would allow selecting the method of representing End of Line
    in the output: CR only, LF only, CR LF sequence
    --
    Steve
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,854
    Likes Received:
    83
    IMO that would be more sensible to implement these as filters instead of
    trying to cram them into TYPE.

    Rex Conn
    JP Software
     
  3. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Steve Fabian:
    | Two independent enhancements are suggested for the TYPE command,
    | useful only if output is piped or redirected:
    |
    | 1/ Unicode/ASCII selection option
    | This option would force output mode regardless of the current
    | state of the UnicodeOutput directive; it might also include specifying
    | codepage.
    |
    | 2/ EOL selection option
    | This option would allow selecting the method of representing End
    | of Line in the output: CR only, LF only, CR LF sequence

    Rex Conn:
    | IMO that would be more sensible to implement these as filters
    | instead of trying to cram them into TYPE.

    Most of us already have filters (eternal programs) to deal with EOLs, it
    would be just a simple convenience to be able to do it internally. Likewise,
    one can issue the appropriate OPTION command to set the value of the
    UnicodeOutput directive before TYPE, and reset it afterwards, or use the
    CHCP command.
    However, TYPE already has the /L, /X and /XS options to change its
    display formats, and it has few options, thus adding these options would
    still leave TYPE as one of the simplest commands.
    --
    Steve
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    On Fri, 17 Sep 2010 15:52:42 -0400, Steve Fábián <>
    wrote:

    || 2/ EOL selection option
    || This option would allow selecting the method of representing End
    || of Line in the output: CR only, LF only, CR LF sequence
    |
    |Rex Conn:
    || IMO that would be more sensible to implement these as filters
    || instead of trying to cram them into TYPE.
    |
    | Most of us already have filters (eternal programs) to deal with EOLs, it
    |would be just a simple convenience to be able to do it internally.

    Tell me what rules it should follow and I'll consider a plugin. There's a
    better chance I'll do it if the rules are simple and don't depend on the input
    (or on the [non-]existence of bogus line-enders). For example, if \r is
    desired, remove all \n's; if \n is desired, remove all \r's; if \r\n is desired,
    condense consecutive \r's to one (or none of no \n follows) and prefix naked
    \n's with a \r (or something like that).

    Could a more generic filter do the job? I mean one which simply replaced
    strings with strings? The search criterion could be expressed as a regex, say
    "\r*\n" and the replacement string with TCC escape characters, say "^n" (or "^r"
    or "^r^n").
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,854
    Likes Received:
    83
    There's no reason a filter would have to be an external (look at TEE).


    Two problems with that assertion:

    1) You'd needlessly limit it to only TYPE output, and

    2) TYPE is probably the fourth most complicated command already, as it also
    includes HEAD and TAIL.

    Rex Conn
    JP Software
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | ---Quote---
    || Most of us already have filters (eternal programs) to deal with
    || EOLs, it would be just a simple convenience to be able to do it
    || internally.
    | ---End Quote---
    | There's no reason a filter would have to be an external (look at
    | TEE).

    I doubt anyone considers TEE to be a filter. Yes, I am well aware that it
    could be in a plug-in (as Vince already offered to do), but some users (not
    I) are leary of using plug-ins that are not Microsoft certified as internal
    features would be.

    | ---Quote---
    || However, TYPE already has the /L, /X and /XS options to change its
    || display formats, and it has few options, thus adding these options
    || would still leave TYPE as one of the simplest commands.
    | ---End Quote---
    | Two problems with that assertion:
    |
    | 1) You'd needlessly limit it to only TYPE output, and
    |
    | 2) TYPE is probably the fourth most complicated command already, as
    | it also includes HEAD and TAIL.

    I agree with #1, and considered expanding the request to ECHO, TEXT,
    HEAD and TAIL. I decided against the expanded request for simplicity, not
    being aware of #2. In view of #2 I now make the additional suggestion to add
    TYPE's /L, /X and /XS options to HEAD and TAIL.
    Furthermore, HEAD/TAIL/TYPE already deal with codeset switching and with
    accepting various styles of EOL in the source data (for selecting lines in
    HEAD/TAIL, or printing line numbers in TYPE). My request would add to
    command parsing the need to dynamically override the default codeset, and to
    select the output EOL style. In the data processing portion it would add a
    switch to replace the EOL found in the source with the one selected by the
    user.
    --
    Steve
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | Tell me what rules it should follow and I'll consider a plugin.
    | There's a better chance I'll do it if the rules are simple and don't
    | depend on the input (or on the [non-]existence of bogus
    | line-enders). For example, if \r is desired, remove all \n's; if \n
    | is desired, remove all \r's; if \r\n is desired, condense
    | consecutive \r's to one (or none of no \n follows) and prefix naked
    | \n's with a \r (or something like that).
    |
    | Could a more generic filter do the job? I mean one which simply
    | replaced strings with strings? The search criterion could be
    | expressed as a regex, say "\r*\n" and the replacement string with
    | TCC escape characters, say "^n" (or "^r" or "^r^n").

    The user must be able to specify EOL independently for input and output.
    I'd offer 3 choices for each: (1) CR, (2) NL (POSIX name for LF), and (3)
    <CR,LF> sequence. I would interpret input for each type as follows:
    (1) CR alone
    Each input CR is translated into an output EOL. Input LF ignored.
    (2) NL (POSIX name for LF)
    Sequence of CRs followed by NL translated into single EOL. Sequence of
    CRs followed by any other character translated into single CR. Each NL
    translated into a single EOL.
    (3) CR LF sequence
    Sequence of CRs followed by LF translated into single EOL. Sequence of
    CRs followed by any other character translated into single CR. Each LF not
    preceded by CR output as is.

    For both input and output choice (1), using CR alone, is least
    important. My rules above are based on the original intent of the CR and LF
    codes, and their customary use in MS-DOS style and Unix style text files. In
    particular, plain CR in styles (2) and (3) is often used to provide
    underscoring or bold printing of text on old printers, and some editors for
    style (3) made files shorter by omitting the CR for blank lines.
    --
    Steve
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    On Tue, 21 Sep 2010 10:01:22 -0400, Steve Fábián <>
    wrote:

    | The user must be able to specify EOL independently for input and output.
    |I'd offer 3 choices for each: (1) CR, (2) NL (POSIX name for LF), and (3)
    |<CR,LF> sequence. I would interpret input for each type as follows:
    |(1) CR alone
    | Each input CR is translated into an output EOL. Input LF ignored.
    |(2) NL (POSIX name for LF)
    | Sequence of CRs followed by NL translated into single EOL. Sequence of
    |CRs followed by any other character translated into single CR. Each NL
    |translated into a single EOL.
    |(3) CR LF sequence
    | Sequence of CRs followed by LF translated into single EOL. Sequence of
    |CRs followed by any other character translated into single CR. Each LF not
    |preceded by CR output as is.

    Where is CR used as a line-ender?

    Could you say it this way? ...

    Let str be a maximal string of CRs and/or LFs from the input file, and let EOL
    denote the target (output file) line-ender ...

    Rule: Replace str with as many EOFs as there appear (in str) CRs (1), LFs (2 and
    3). I don't like leaving CRs in a file with LFs as EOLs.
     
  9. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | Where is CR used as a line-ender?

    In a previous discussion someone mentioned a current usage. Personally
    I've seen it only in the old TRS-80s.

    |
    | Could you say it this way? ...
    |
    | Let str be a maximal string of CRs and/or LFs from the input file,
    | and let EOL denote the target (output file) line-ender ...
    |
    | Rule: Replace str with as many EOLs as there appear (in str)
    | CRs (1),
    | LFs (2 and 3).

    Reasonable.

    | I don't like leaving CRs in a file with LFs as EOLs.

    It is not superfluous to have CRs in a file which uses LF as EOL (*nix
    style) if between each CR and the subsequent LF there is at least one
    printable (non-white) character. Indicates "overprinting".
    OTOH the use of LF in style (1) is suspcious.
    --
    Steve
     
  10. jmcm

    Joined:
    Jun 11, 2008
    Messages:
    26
    Likes Received:
    0
    On 22/09/2010 2:02 AM, Steve F�bi�n wrote:

    I may be wrong (never had one), I think that Apple Mac (possibly only
    pre OSX) use a single CR as EOL.


    --
    Regards
    John McMahon
    lists@jspect.fastmail.fm
     

Share This Page