I forgot to put in a diff. Sorry.
Index: pathnames.h
===
RCS file: /cvs/src/usr.sbin/lpr/common_source/pathnames.h,v
retrieving revision 1.6
diff -u -p -r1.6 pathnames.h
--- pathnames.h 28 Oct 2015 13:25:55 - 1.6
+++
These should be correct diff's this time. My vim was too perl oriented,
not now.
These three are intimately tied together, so I think they should be
completely removed. If one of these types of printing is done by
someone, it can be dealt with by some future filter.
tex or dvi are names used for
--- rdist.1.origMon Feb 22 18:48:45 2016
+++ rdist.1Mon Feb 22 18:49:29 2016
@@ -117,7 +117,7 @@
.Pp
Otherwise,
.Nm
-run will run the command:
+will run the command:
.Bd -literal -offset indent
ssh \*(Lthost\*(Gt -l \*(Ltlogin_name\*(Gt rdistd -S
.Ed
On Mon, 22 Feb 2016, Martin Brandenburg wrote:
> Is there another sort of menu I'm not thinking of? I'll
> admit to not using all of cwm's features.
Ooh! Right after sending this I accidentally hit CM-n,
and it crashed since menu_filter wasn't supposed to
return NULL.
Well what was in there
On Sat, 20 Feb 2016, Okan Demirmen wrote:
> On Sat 2016.02.20 at 12:29 -0500, Martin Brandenburg wrote:
> > This avoids an empty square in the upper left corner if
> > there is nothing to display in some menu the user
> > requests.
>
> Sorry, but I think that is a big hammer; in fact there is
On Mon, Feb 22, 2016 at 06:31:00AM -0700, Todd C. Miller wrote:
> On Sun, 21 Feb 2016 16:33:27 +0100, Stefan Kempf wrote:
>
> > Should we really mount the FS in that case? If the FS was of the
> > "new" format, then short symlinks would store the destination path in the
> > inode directly. I
Sun, 21 Feb 2016 12:41:06 -0700 Theo de Raadt
> As to the 0x entry, I'm wondering whether it should be named something
> like the following, as a historical reminder:
>
> +product FTDI FT232_JERKS 0xSerial
Others followed suit too, HL_340 bricked clones
On Sun, 21 Feb 2016 16:33:27 +0100, Stefan Kempf wrote:
> Should we really mount the FS in that case? If the FS was of the
> "new" format, then short symlinks would store the destination path in the
> inode directly. I think we'd not be able to correctly follow these symlinks
> if we set