| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
OK sthen@
|
| |
|
|
| |
OK sthen@
|
| |
|
|
| |
Timing is good deraadt@, OK sthen@
|
| |
|
|
| |
Timing is good deraadt@, OK sthen@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
which tried to figure out whether mandoc supported UTF-8 output
(which it has been doing since 2011) and which passed the -T locale
option (which has been the default since 2014 and always will)
but which required the -V option to work (which was deleted half
a decade ago and will not come back).
Nowadays, it is safe to assume that mandoc just works with UTF-8
on both the input and output sides - in literally each and every
operating system providing a mandoc port or package, even those
that are seriously lagging behind.
This patch will also be pushed upstream.
OK tb@
|
| | |
|
| |
|
|
|
|
|
| |
Minor bugfixes and documentation improvments. See perldelta for details.
https://metacpan.org/pod/release/SHAY/perl-5.28.2/pod/perldelta.pod
OK bluhm@
|
| |
|
|
|
|
|
|
|
|
|
| |
variable and fall back to what stty(1) reports, and it does so with
nroff(1), but it didn't with mandoc(1) because it didn't know how
to pass the desired width to mandoc. Teach it to use "-O width=".
OK afresh1@.
I noticed the unimplemented feature when Andrew Daugherity asked
on tech@ what the point of a certain patch in FreeBSD is (which it
turns out we don't need).
|
| |
|
|
|
|
|
|
|
|
|
| |
output in UTF-8 encoding on OpenBSD. The consumer is always mandoc(1)
on OpenBSD, which can always handle UTF-8 input (no matter what LC_CTYPE
is) and which always produces useful output: UTF-8 for LC_CTYPE=*.UTF-8
or ASCII otherwise, in particular for LC_CTYPE=C.
Patch written after afresh1@ reported that "perldoc -oman" output
looked bad in both output modes.
OK afresh1@.
|
| |
|
|
|
|
| |
From Andrew Daugherity <andrew.daugherity () gmail ! com>
Corrections to fix and OK millert@, suggestions and OK schwarze@
|
| |
|
|
| |
looking good sthen@, Great! bluhm@
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem relates to Perl 5 ("perl") loading modules from the
includes directory array ("@INC") in which the last element is the
current directory ("."). That means that, when "perl" wants to
load a module (during first compilation or during lazy loading of
a module in run-time), perl will look for the module in the current
directory at the end, since '.' is the last include directory in
its array of include directories to seek. The issue is with requiring
libraries that are in "." but are not otherwise installed.
The major problem with this behavior is that it unexpectedly puts
a user at risk whenever they execute any Perl scripts from a directory
that is writable by other accounts on the system. For instance, if
a user is logged in as root and changes directory into /tmp or an
account's home directory, it is possible to now run any shell
commands that are written in C, Python or Ruby without fear.
The same isn't true for any shell commands that are written in Perl,
since a significant proportion of Perl scripts will execute code
in the current working directory whenever they are run. For example,
if a user on a shared system creates the file /tmp/Pod/Perldoc/Toterm.pm,
and then I log in as root, change directory to /tmp, and run "perldoc
perlrun", it will execute the code they have placed in the file.
ok deraadt@
|
| |
|
|
| |
ok deraadt@ sthen@ espie@ miod@
|
| | |
|
| |
|
|
| |
OK espie@ sthen@ deraadt@
|
| |
|
|
| |
OK espie@ sthen@ deraadt@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
because that resulted in corrupt output.
This is a verbatim backport of the following bugfix from upstream git master:
https://rt.cpan.org/Public/Bug/Display.html?id=77465
https://github.com/mrallen1/Pod-Perldoc/commit/6e1541d0bcb74a7b2b9ee3235d57953fb800bb67
Do not take the comment in the source code too literally.
It doesn't really explain the problem well.
OK sthen@ espie@ millert@
|
| |
|
|
|
| |
Will send this upstream as well.
OK millert@ bluhm@ stsp@
|
| |
|
afresh1
schwarze
sthen