jules@zen.co.uk (Julian Perry) (09/20/88)
THIS IS AN UNOFFICIAL PATCH! -- Can it be made official and correctly
integrated with the rest of the less
distribution?
This patch (apply using `patch') solves 2 problems and adds one feature:
1) Bug if you have a SHELL variable and set globbing....calloc() was
not being passed a second paramter, and the first parameter was
wrong anyway.
2) Screen updating was wrong on HP terminals (where have I heard that
before?) because the off-screen memory was not being cleared at the
right times. The fix included is NOT the best way of solving the
problem, but it does work.
**** NEW FEATURE ****
Not wishing to be accused of creeping featurism......I think it's
really useful:
less can now display `compress'ed, `pack'ed and `compact'ed files
without the user needing to uncompress them. This only works for
files specified on the command line. It has been implemented
so that it can be expanded to cope with other forms of encoding.
The filename of the compressed file must be specified WITH the .Z
suffix (or .z or .C).
I hope this is as useful to you as it is to me ...
less is wonderful....thanks,
Jules
IN-REAL-LIFE: Julian Perry
E-MAIL: jules@zen.co.uk || ...!uunet!mcvax!ukc!zen.co.uk!jules
PHONE: +44 532 489048 ext 217
ADDRESS: Zengrange Limited, Greenfield Road, Leeds, England, LS9 8DB
*** SAFE/funcs.h Tue Sep 20 12:17:13 1988
--- funcs.h Tue Sep 20 12:24:12 1988
***************
*** 54,59
public void vbell ();
public void clear ();
public void clear_eol ();
public void so_enter ();
public void so_exit ();
public void ul_enter ();
--- 54,60 -----
public void vbell ();
public void clear ();
public void clear_eol ();
+ public void clear_eos ();
public void so_enter ();
public void so_exit ();
public void ul_enter ();
*** SAFE/command.c Tue Sep 20 12:17:13 1988
--- command.c Tue Sep 20 12:23:57 1988
***************
*** 699,705
* Help.
*/
lower_left();
! clear_eol();
putstr("help");
cmd_exec();
help();
--- 699,705 -----
* Help.
*/
lower_left();
! clear_eos();
putstr("help");
cmd_exec();
help();
*** SAFE/main.c Tue Sep 20 12:17:15 1988
--- main.c Tue Sep 20 15:42:47 1988
***************
*** 55,60
register char *m;
POSITION initial_pos;
char message[100];
static int didpipe;
initial_pos = NULL_POSITION;
--- 55,61 -----
register char *m;
POSITION initial_pos;
char message[100];
+ int new_file_ispipe = 0;
static int didpipe;
initial_pos = NULL_POSITION;
***************
*** 89,94
return;
}
f = 0;
} else if ((m = bad_file(filename, message, sizeof(message))) != NULL)
{
error(m);
--- 90,96 -----
return;
}
f = 0;
+ new_file_ispipe = 1;
} else if ((m = bad_file(filename, message, sizeof(message))) != NULL)
{
error(m);
***************
*** 100,105
free(filename);
return;
}
if (isatty(f))
{
--- 102,108 -----
free(filename);
return;
}
+ #ifndef NO_JULES_HACKS
/* These are for the machines that I have.... */
# define COMPRESS /* Everyone has compress - don't they? */
***************
*** 101,106
return;
}
if (isatty(f))
{
/*
--- 104,210 -----
}
#ifndef NO_JULES_HACKS
+ /* These are for the machines that I have.... */
+ # define COMPRESS /* Everyone has compress - don't they? */
+ # ifdef hpux
+ # define PACK
+ # if defined(hp9000s300) || defined(hp9000s500)
+ # define COMPACT /* Why doesn't the Specky have compact ??? */
+ # endif
+ # endif
+
+ /* Let's check for a compressed file and uncompress it for display */
+ else
+ {
+ /* This table defines which program to run given the magic number
+ at the start if the file */
+ static struct
+ {
+ int magic_length;
+ unsigned char bytes[4];
+ int filename_needed;
+ char *program_name;
+ } programs[] = {
+ # ifdef COMPRESS
+ { 2, 0x1f, 0x9d, 0x0, 0x0, 0, "uncompress" },
+ # endif
+ # ifdef PACK
+ { 2, 0x1f, 0x1e, 0x0, 0x0, 1, "pcat" },
+ # endif
+ # ifdef COMPACT
+ { 2, 0xff, 0x1f, 0x0, 0x0, 0, "uncompact" },
+ # endif
+ { 0, 0x0, 0x0, 0x0, 0x0, 0, NULL }
+ };
+ unsigned char magic[4];
+ int loop;
+ int b;
+ int fd[2];
+ int pid;
+
+ if ( read(f,magic,sizeof(magic)) <= 0 )
+ lseek(f,0L,0);
+ else
+ {
+ lseek(f,0L,0);
+
+ for ( loop = 0 ; programs[loop].magic_length ; ++loop )
+ {
+ for ( b = 0 ;
+ (b < programs[loop].magic_length) &&
+ (programs[loop].bytes[b] == magic[b]) ;
+ ++b )
+ ;
+ if ( b == programs[loop].magic_length )
+ break;
+ }
+
+ if ( programs[loop].magic_length )
+ {
+ if ( pipe(fd) < 0 )
+ {
+ error(errno_message(filename, message, sizeof(message)));
+ free(filename);
+ return;
+ }
+
+ /* Vfork() might be allowed - but let's not chance it */
+ if ( (pid = fork()) < 0 )
+ {
+ error(errno_message(filename, message, sizeof(message)));
+ free(filename);
+ close(f);
+ close(fd[0]);
+ close(fd[1]);
+ return;
+ }
+
+ if ( !pid )
+ {
+ close(0);
+ dup(f);
+ close(f);
+ close(1);
+ dup(fd[1]);
+ close(fd[0]);
+ if ( programs[loop].filename_needed )
+ execlp(programs[loop].program_name,
+ programs[loop].program_name,filename,0);
+ else
+ execlp(programs[loop].program_name,
+ programs[loop].program_name,0);
+ _exit(127);
+ }
+
+ close(fd[1]);
+ close(f);
+ f = fd[0];
+ new_file_ispipe = 2;
+ }
+ }
+ }
+ #endif
+
if (isatty(f))
{
/*
***************
*** 133,140
previous_file = current_file;
current_file = filename;
prev_pos = position(TOP);
! ispipe = (f == 0);
! if (ispipe)
didpipe = 1;
file = f;
ch_init(cbufs, 0);
--- 237,244 -----
previous_file = current_file;
current_file = filename;
prev_pos = position(TOP);
! ispipe = new_file_ispipe;
! if (f == 0)
didpipe = 1;
file = f;
ch_init(cbufs, 0);
***************
*** 446,452
end_logfile();
#endif
lower_left();
! clear_eol();
deinit();
flush();
raw_mode(0);
--- 550,556 -----
end_logfile();
#endif
lower_left();
! clear_eos();
deinit();
flush();
raw_mode(0);
*** SAFE/os.c Tue Sep 20 12:17:15 1988
--- os.c Tue Sep 20 16:16:28 1988
***************
*** 44,50
else
{
lower_left();
! clear_eol();
putstr("!");
putstr(cmd);
putstr("\n");
--- 44,50 -----
else
{
lower_left();
! clear_eos();
putstr("!");
putstr(cmd);
putstr("\n");
***************
*** 201,207
/*
* Read the output of <$SHELL -c "echo filename">.
*/
! cmd = calloc(strlen(p)+12);
if (cmd == NULL)
return (filename);
sprintf(cmd, "%s -c \"echo %s\"", p, filename);
--- 201,207 -----
/*
* Read the output of <$SHELL -c "echo filename">.
*/
! cmd = calloc(strlen(p)+strlen(filename)+12, sizeof(char));
if (cmd == NULL)
return (filename);
sprintf(cmd, "%s -c \"echo %s\"", p, filename);
*** SAFE/prim.c Tue Sep 20 12:17:16 1988
--- prim.c Tue Sep 20 12:25:49 1988
***************
*** 116,122
} else
{
lower_left();
! clear_eol();
}
if (pos != position(BOTTOM_PLUS_ONE))
--- 116,122 -----
} else
{
lower_left();
! clear_eos();
}
if (pos != position(BOTTOM_PLUS_ONE))
*** SAFE/prompt.c Tue Sep 20 12:17:16 1988
--- prompt.c Tue Sep 20 14:41:07 1988
***************
*** 129,135
case 'e': /* At end of file? */
return (hit_eof);
case 'f': /* Filename known? */
! return (!ispipe);
case 'l': /* Line number known? */
return (linenums);
case 'm': /* More than one file? */
--- 129,135 -----
case 'e': /* At end of file? */
return (hit_eof);
case 'f': /* Filename known? */
! return (ispipe != 1);
case 'l': /* Line number known? */
return (linenums);
case 'm': /* More than one file? */
*** SAFE/screen.c Tue Sep 20 12:17:17 1988
--- screen.c Tue Sep 20 12:22:04 1988
***************
*** 42,47
*sc_move, /* General cursor positioning */
*sc_clear, /* Clear screen */
*sc_eol_clear, /* Clear to end of line */
*sc_s_in, /* Enter standout (highlighted) mode */
*sc_s_out, /* Exit standout mode */
*sc_u_in, /* Enter underline mode */
--- 42,48 -----
*sc_move, /* General cursor positioning */
*sc_clear, /* Clear screen */
*sc_eol_clear, /* Clear to end of line */
+ *sc_eos_clear, /* Clear to end of screen */
*sc_s_in, /* Enter standout (highlighted) mode */
*sc_s_out, /* Exit standout mode */
*sc_u_in, /* Enter underline mode */
***************
*** 279,284
sc_eol_clear = "";
}
sc_clear = tgetstr("cl", &sp);
if (hard || sc_clear == NULL || *sc_clear == '\0')
{
--- 280,292 -----
sc_eol_clear = "";
}
+ sc_eos_clear = tgetstr("cd", &sp);
+ if (hard || sc_eos_clear == NULL || *sc_eos_clear == '\0')
+ {
+ cannot("clear to end of screen");
+ sc_eos_clear = "";
+ }
+
sc_clear = tgetstr("cl", &sp);
if (hard || sc_clear == NULL || *sc_clear == '\0')
{
***************
*** 493,498
clear_eol()
{
tputs(sc_eol_clear, 1, putchr);
}
/*
--- 501,516 -----
clear_eol()
{
tputs(sc_eol_clear, 1, putchr);
+ }
+
+ /*
+ * Clear from the cursor to the end of the screen (memory).
+ * {{ This must not move the cursor. }}
+ */
+ public void
+ clear_eos()
+ {
+ tputs(sc_eos_clear, 1, putchr);
}
/*
*** SAFE/signal.c Tue Sep 20 12:17:17 1988
--- signal.c Tue Sep 20 12:26:16 1988
***************
*** 166,172
SIGNAL(SIGTTOU, SIG_IGN);
#endif
lower_left();
! clear_eol();
deinit();
flush();
raw_mode(0);
--- 166,172 -----
SIGNAL(SIGTTOU, SIG_IGN);
#endif
lower_left();
! clear_eos();
deinit();
flush();
raw_mode(0);
--
IN-REAL-LIFE: Julian Perry
E-MAIL: jules@zen.co.uk || ...!uunet!mcvax!ukc!zen.co.uk!jules
PHONE: +44 532 489048 ext 217
ADDRESS: Zengrange Limited, Greenfield Road, Leeds, England, LS9 8DBdavidsen@steinmetz.ge.com (William E. Davidsen Jr) (09/28/88)
Could I suggest that it would be appropriate to have the author gather
all of the patches, evaluate them, and either release a new version or a
single patch file which will apply all of the valid fixes?
Also, as useful as the ability to read some compressed file formats is,
I would rather keep less small and use the appropriate utility piped
into less when needed. (That's an opinion)
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mejbayer@ispi.UUCP (id for use with uunet/usenet) (09/28/88)
In article <12247@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > Could I suggest that it would be appropriate to have the author gather > all of the patches, evaluate them, and either release a new version or a > single patch file which will apply all of the valid fixes? > > Also, as useful as the ability to read some compressed file formats is, > I would rather keep less small and use the appropriate utility piped > into less when needed. (That's an opinion) As the summary states: K(eep) I(t) S(imple) S(tupid). In other words, I am in full agreement to keep the decompression stuff out of less. Jonathan Bayer Intelligent Software Products, Inc.
charles@hpcvca.HP.COM (Charles Brown) (09/30/88)
> Could I suggest that it would be appropriate to have the author gather > all of the patches, evaluate them, and either release a new version or a > single patch file which will apply all of the valid fixes? > bill davidsen (wedu@ge-crd.arpa) At least some of these fixes have been sent to the author several times over the past 3 years. It WOULD be appropriate for the author to implement the fixes. So far he has not. In particular the incorrect behaviour of less with HP terminals has been reported several times. Because this has to be patched each time the sources come out, I stopped upgrading less at this site back in 1986 with version 61. So as long as less continues to come out with the same compatibility problem, others will continue to supply patches. To the author of these patches I say "Thank you". To the author of less I say "Thank you for writing it". But I am a little frustrated that these fixes are repeatedly ignored. When I sent the same set of fixes (independently created 2 years ago) my mail was not even agknowledged. -- Charles Brown charles%hpcvca@hplabs.hp.com Not representing my employer.
dupuy@douglass.columbia.edu (Alexander Dupuy) (09/30/88)
In article <12247@steinmetz.ge.com>, davidsen@steinmetz.ge.com writes: > Also, as useful as the ability to read some compressed file formats is, > I would rather keep less small and use the appropriate utility piped > into less when needed. (That's an opinion) In article <198@ispi.UUCP>, jbayer@ispi.UUCP agrees. I have to differ on this. While I agree with the philosophy of keeping the functionality of less limited to displaying text files, if either of you had looked closely at the posted code, you would see that it does exactly what you would be doing manually, i.e. using the appropriate utility piped into less. There is a pretty good tradition of having one unix utility forking off another to do part of its work; find -cpio, Gilmore's pdtar -z (which uses uncompress in exactly the way the less patches do), to name the first which come to mind. The only argument against the patches which I would concede has any validity is the law of least surprise - normally, piping the output of less (or more) reduces its functionality to that of cat. But I think the advantage of being able to read compressed files directly, _regardless of compression format_, outweighs the arguments against. @alex -- inet: dupuy@columbia.edu uucp: ...!rutgers!columbia!dupuy
mikew@tahoe.unr.edu (Mike Wishart) (10/01/88)
In article <198@ispi.UUCP>, jbayer@ispi.UUCP (id for use with uunet/usenet) writes: ! In article <12247@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: ! ! As the summary states: K(eep) I(t) S(imple) S(tupid). In other words, I am ! in full agreement to keep the decompression stuff out of less. ! Why? The decompression stuff is transparent and so much easier than having to uncompress the file before reading or piping it through zcat (If your system has it). It's great, I keep docs compressed now so that I can read them whenever and not worry about them taking up bouco space. Maybe a switch in the makefile (I believe it's there, if you don't want it you can use a -DNO_JULES <I think>, maybe change it to NO_DECO for better understanding). __ _ _ _ _ ' ) ) ) / ' ) / / _/_ / / / o /_ _ / / / o _ /_ __. __ / / ' (_<_/ <_</_ (_(_/ <_/_)_/ /_(_/|_/ (_<__ -------------------------------------------------------------------------------- Politician, n. A waste of time, energy, money, gravity, and space. -- Mike Wishart
mark@UNIX386.Convergent.COM (Mark Nudelman) (10/04/88)
In article <4300004@hpcvca.HP.COM>, charles@hpcvca.HP.COM (Charles Brown) writes: > At least some of these fixes have been sent to the author several > times over the past 3 years. It WOULD be appropriate for the author to > implement the fixes. So far he has not. > > In particular the incorrect behaviour of less with HP terminals has > been reported several times. Because this has to be patched each time > the sources come out, I stopped upgrading less at this site back in > 1986 with version 61. > > To the author of less I say "Thank you for writing it". But I am a > little frustrated that these fixes are repeatedly ignored. When I > sent the same set of fixes (independently created 2 years ago) my mail > was not even agknowledged. > -- > Charles Brown charles%hpcvca@hplabs.hp.com > Not representing my employer. As the author of "less", I have received literally hundreds of mail items concerning the program over the past few years. I've gotten everything from glowing praise to nasty-grams because someone's favorite feature hasn't been included. While I can understand your frustration, I'd like to make a few points. A large fraction of the mail I've received has included suggested code changes. Evaluating and integrating these changes is a time-consuming, altho sometimes enjoyable, task. I have, despite the large volume of mail, attempted to answer every note I've received. If I didn't respond to your mail, I almost certainly never received it. I'm surprised that you took a lack of response as a lack of interest, rather than the more obvious lack of receipt. Second, concerning the specific problem you mention with HP terminals, I do not have access to an HP terminal. I have to evaluate the changes concerning such terminals based on what other people tell me. When I posted my very first version of less, over three years ago, I got various complaints about it not working on different kinds of terminals. I also got several (incompatible) suggestions on how to fix it for each particular type of terminal. In regard to the problem with terminals with off-screen memory, I was told that the termcap "ti" string should set up the terminal so that the on-screen memory was the only accessible memory, in effect making these terminals appear like "normal" terminals; and that people who complained had a broken termcap description. I nevertheless tried to integrate the fixes, without a way to test the result. After my first attempt at a fix, I got complaints that less no longer worked on some terminals; so I tried again. Now you say it still doesn't work on some terminal. Frankly, I'm not surprised. But I'm a bit at a loss as to how to proceed. Can you guarantee that your change will make it work on every terminal, and won't break anything? If so, then I'll gladly incorporate your change. If not, I'll probably incorporate it anyway; I've tried to be very generous in acceptance of new code, which is one of the reasons less is getting as large and baroque as it is. I am, by the way, evaluating and integrating the recent postings on the net. The ones which are clearly bug fixes will of course go in. My current thinking is that the decrypting/unpacking stuff just doesn't belong there; pipes suffice. The others I am still evaluating. Finally, you're welcome. Mark Nudelman {sun,decwrl,hplabs}!pyramid!ctnews!UNIX386!markn
charles@hpcvca.HP.COM (Charles Brown) (10/05/88)
> A large fraction of the mail I've received has included suggested code > changes. Evaluating and integrating these changes is a time-consuming, > altho sometimes enjoyable, task. I have, despite the large volume of > mail, attempted to answer every note I've received. If I didn't > respond to your mail, I almost certainly never received it. I'm > surprised that you took a lack of response as a lack of interest, > rather than the more obvious lack of receipt. Your response here tells me that I was wrong in thinking that you were deliberately ignoring my messages. Please understand my assumption was based upon a lack of response to three messages. (2 email, 1 notes) > Second, concerning the specific problem you mention with HP terminals, > I do not have access to an HP terminal. I have to evaluate the changes > concerning such terminals based on what other people tell me. Perhaps I can be of assistance. I am willing (time permitting) to try out less on a pre-release basis and report back to you any problems I find. > In regard to the problem with terminals with off-screen memory, I > was told that the termcap "ti" string should set up the terminal so > that the on-screen memory was the only accessible memory, in effect > making these terminals appear like "normal" terminals; and that > people who complained had a broken termcap description. This is the first time I heard of this. I did not save this version for myself (since I prefer to use a version with emacs bindings hacked in and I don't currently have time to hack them in) but passed it on to a friend whose computer is unreachable by me. So I cannot check this: did you or can you mention this in some of the documentation? Of course I will need to check that this does not break other software... > I nevertheless tried to integrate the fixes, without a > way to test the result. After my first attempt at a fix, I got > complaints that less no longer worked on some terminals; so I tried > again. Now you say it still doesn't work on some terminal. Frankly, > I'm not surprised. But I'm a bit at a loss as to how to proceed. Can > you guarantee that your change will make it work on every terminal, and > won't break anything? If so, then I'll gladly incorporate your change. > If not, I'll probably incorporate it anyway; I've tried to be very > generous in acceptance of new code, which is one of the reasons less is > getting as large and baroque as it is. Clearly I cannot make such a guarantee. I have access to only a few types of non-HP terminals. The more I learn about the different escape sequence languages for all the different types of terminals in the industry, the more amazed I am that termcap and curses work as well as they do. In fact, even with this incompatibility of less with HP terminals, it still works most of the time. > I am, by the way, evaluating and integrating the recent postings on the > net. The ones which are clearly bug fixes will of course go in. > Mark Nudelman Thank you. I could ask for no more. -- Charles Brown charles%hpcvca@hplabs.hp.com Not representing my employer.
lmb@vsi1.UUCP (Larry Blair) (10/06/88)
In article <4300005@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes:
=I did not save this version
=for myself (since I prefer to use a version with emacs bindings hacked
=in and I don't currently have time to hack them in)
V97 of less provides the "lesskey" program. This allows you to set any
bindings that you want to. No more hacks are necessary.
Given the abuse that has been heaped on Mark for providing the world a
truly useful utility, I'm amazed that anyone would bother to post their
work.
--
Larry Blair ames!vsi1!lmb lmb%vsi1@ames.arc.nasa.govallbery@ncoast.UUCP (Brandon S. Allbery) (10/13/88)
As quoted from <4300005@hpcvca.HP.COM> by charles@hpcvca.HP.COM (Charles Brown): +--------------- | Your response here tells me that I was wrong in thinking that you were | deliberately ignoring my messages. Please understand my assumption | was based upon a lack of response to three messages. (2 email, 1 | notes) +--------------- Sometimes we get the messages but replies always bounce. And some people don't have time to read ALL of news.... +--------------- | > In regard to the problem with terminals with off-screen memory, I | > was told that the termcap "ti" string should set up the terminal so | > that the on-screen memory was the only accessible memory, in effect | > making these terminals appear like "normal" terminals; and that | > people who complained had a broken termcap description. | | This is the first time I heard of this. I did not save this version +--------------- I am always amized at the number of termcap (and terminfo!) entries which wee obviously written by someone who never read termcap(4) in the manual. "ti"/"te" (terminfo: "smcup"/"rmcup") are clearly documented and so is this usage in particular. THE CARDINAL RULE OF PROGRAMS USING SMART I/O: If a program known to work on many terminals doesn't work on yours, CHECK THE TERMCAP/TERMINFO DESCRIPTION FIRST!!! It's absolutely amazing how many terminal descriptions are absolute trash! (I've got Wyse 50 termcaps that have "DL=/EW" (notice the FORWARD slash) in them. And ncoast's sysop, on seeing the result of this, claimed that the *terminal* had to be broken.) ++Brandon -- Brandon S Allbery uunet!hal.cwru.edu!ncoast!allbery allbery%ncoast@hal.cwru.edu (LAST RESORT ONLY: allbery@uunet.uu.net) DELPHI: ALLBERY comp.sources.misc is moving off ncoast -- please do NOT send submissions direct "So many articles, so little time...." -- The Line-Eater