Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Done Enhanced TYPE command

May
3,515
5
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
 
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
 
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").
 
> 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.

There's no reason a filter would have to be an external (look at TEE).


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

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
 
| ---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
 
| 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
 
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.
 
| 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
 
On 22/09/2010 2:02 AM, Steve F�bi�n wrote:

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

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


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

--
Regards
John McMahon
[email protected]
 

Similar threads

Back
Top