« first day (135 days earlier)      last day (2264 days later) » 

12:28 AM
@Zanna I am able to reproduce this problem on Lubuntu 17.10. So it does appear to be a regression. Have you reported it as a bug? Do you want to do so? (If you don't want to do it, then I am totally willing to do it. However, I think you have easier access to 17.10 than I do, and should be able to provide any information requested by triagers or developers more readily. You can let me know.)
Should it be considered the same as this bug?
Fresh konsole: $ echo $TERM xterm-256color $ type perldoc perldoc is /usr/bin/perldoc $ dpkg -S /usr/bin/perldoc diversion by perl-doc from: /usr/bin/perldoc diversion by perl-doc to: /usr/bin/perldoc.stub perl, perl-doc: /usr/bin/perldoc $ echo $PAGER $ perldoc perlsyn (Now in pager:) ESC[1mNAMEESC[0m perlsyn - Perl syntax ESC[1mDESCRIPTIONESC[0m A Perl program consists of a sequence of declarations and statements which ... That's a lot of ESCapes. PAGER=more gets me "2NAME2" and the like. $ locate perlsyn /usr/share/man/man1/perlsyn.1.gz /usr/share/man/man1/perlsynology.1.gz /usr/share/perl/5.26.0/pod/perlsyn.pod /usr/share/perl/5.26.0/pod/perlsynology.pod No cached files apparently. This works reasonably: TERM=none perldoc perlsyn | (TERM=vt100 less) - but looses the bolds etc. This works well: man perlsyn This also works as expected, showing bolds and stuff, but I find it impractical: perldoc perlsyn | cat So perldoc applies terminal appropriate escapes w
perl (Ubuntu)
Undecided / New
The problem looks to me that it might be universal to all 17.10 users! After all, I didn't have to do anything at all special to produce it, and I don't think my 17.10 system is especially similar to yours. If that's the case, then the stuff about xterm-256color might make it seem as if it's not. OTOH is that just what you usually get in GNOME Terminal? I don't have a system with GNOME Terminal or MATE Terminal. What's your $TERM?
 
 
9 hours later…
9:47 AM
$ echo $TERM
xterm
 
Maybe it's set to xterm-256color with GNOME Terminal but not with MATE Terminal. Anyway, this doesn't seem to probably be an important detail. Is there any justification for opening a new bug report? If not, we can comment on the existing one and we can each mark it as affecting us (which will change its status to Confirmed).
 
looks like that person is using Konsole?
 
Oh. Right.
 
or do they mean fresh console haha
 
No, it's Konsole, you're right. There's no reason to think otherwise, plus they installed from Kubuntu installation media (before upgrading by one release to 17.10).
 
9:50 AM
in GNOME terminal:
$ echo $TERM
xterm-256color
 
Ah, okay. So GNOME Terminal sets that too.
My Lubuntu 17.10 system has LXTerminal.
 
I get the same in Konsole as in GNOME terminal
 
Anyway, I see no reason to think the terminal type is important.
 
but all these emulators show the same issue with the escapes (and it occurs in VCs too)
 
I mean, you could have a terminal that didn't support any highlighting or color. What I mean is that there's no reason to think the terminal is important to this specific bug. Yeah.
 
9:52 AM
agreed
 
So, no reason to think we have a different bug?
Do you want to comment, or shall I?
 
not that I can see - seems like the same bug
 
I mean, we can both comment, but there is probably no need to reproduce lots of information across our two comments.
 
What should the comment include? Simplest workaround pass -t... Bug seems like a regression since it was fixed in version 52 by that code to pass -R to less (I think?) which was apparently replaced with that code which seems not to fix this issue...
I think it will be a better comment if you write it, because you understand the issue better...
I marked myself as affected by the bug
 
@Zanna I can write it. But that's pretty much what I will write. I mean, I'll use complete sentences and probably include the code fragments directly in the comment, but the only additional material I plan to include is the fuller workaround of passing a value for the LESS environment variable that contains -R.
 
10:08 AM
Well experienced with unatennded-upgrades? Please share from your experience with us here: askubuntu.com/questions/993470/…
 
@EliahKagan hmm sounds good
 
10:25 AM
@Zanna Is it okay with you if I include a link to your Launchpad profile (possibly as well as your Ask Ubuntu profile) in identifying you as the user, besides me, who had the bug and confirmed the workarounds? I will, of course, run all the workarounds that I include in the comment by you, before submitting the comment.
If so, can you give me a link to your Launchpad profile? I don't actually know your Launchpad username. Alternatively, if you subscribe to email notifications on the bug report then I should be able to see a link to your Launchpad profile there (in case you had been planning to do that anyway).
 
@EliahKagan sure!
I subscribed. But anyway my profile is here
 
I'm, uh, still waiting for my 17.10 virtual machine to start...
I should never have shut it down. :)
 
haha I know how it feels
 
It's still starting.
 
10:42 AM
Me too. Maybe I should try loading additional hot beverage...
 
So you don't have a usable 17.10 system at the moment either?
 
My 17.10 system is fine. It's the user who's lagging. Can I do something helpful with my system right now?
 
Yes. I'll need mine working to finish my bug comment, but can you test the workaround just to be sure we're not making a mistake?
LESS=-R perldoc perlsyn
LESS="$LESS -R" perldoc perlsyn
perldoc perlsyn | less -R
And the simpler workaround:
perldoc -t perlsyn
 
11:00 AM
@EliahKagan works
@EliahKagan works
they all work
 
Great!
 
:)
 
Is your Perldoc.pm file on 17.10 identical to this one?
 
diff says so
 
So, I am pretty sure this is intended to place -R to LESS, when necessary:
                  $formatter->pager_configuration($pager, $self);
What's the output, besides the actual document displayed, when you pass the -D option?
perldoc -D perlsyn
 
11:18 AM
$ perldoc -D perlsyn
Ending switch processing.  Args are [perlsyn] with 0 errors.
Pagers: /usr/bin/sensible-pager, more, less, pg, view, cat/usr/bin/perldoc => Pod::Perldoc v3.28

Formatter class Pod::Perldoc::ToTerm version 3.28 successfully loaded!
Will format with the class Pod::Perldoc::ToTerm
Searching for perlsyn
Looking for perlsyn in /usr/bin /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu
 
How about:
PAGER=less perldoc perlsyn
 
that looks fine
 
So I can document it for the bug comment, what terminals have you tested it with? I don't mean all these workarounds. But what terminals have you seen the bug with? You've gotten in in a virtual console, XTerm, and MATE Terminal, right? What else?
 
11:37 AM
Besides what you mentioned, I also observe the problem in GNOME terminal, Konsole and Tilda
 
Can you tell me what $TERM expands to, in each of the terminals you've tested this in?
 
MATE terminal:
$ echo $TERM
xterm
tilda:
$ echo $TERM
xterm-256color
I also get xterm-256color in Konsole and GNOME terminal
In XTerm I get xterm
 
And it's linux in a virtual console?
 
yes
 
11:54 AM
@Zanna Are you willing to read over a draft of the comment?
 
definitely :)
 
This bug affects my Lubuntu 17.10 (64-bit) system, which has version 5.26.0-8ubuntu1 of the perl and perl-doc packages. I noticed the bug immediately upon checking for it after Zanna (launchpad.net/~rose-anna-bleasdale / askubuntu.com/users/527764/zanna) reported experiencing it in Ubuntu MATE 17.10. Until this bug is fixed, I suggest the workaround of setting the PAGER environment variable to "less" so that the proper configuration for less is used; other full workarounds are also effective (see below).
 
looks great!
 
Cool. I've posted my comment on bug 1734702. Thank you for your help!
So, for your case, if you're running perldoc a lot, then you could make it an alias that uses one of the workarounds shown, or you could just put export PAGER=less in ~/.profile or wherever you prefer to define environment variables.
 
thanks a lot for writing and posting the comment ^_^
 
12:06 PM
No problem.
@Zanna Btw, I figured out why it runs sh.
 
oh yeah? I was thinking maybe it does that to be more sure of getting a shell that supports something it wants. Not that sh is obliged to be any particular shell...
 
It has:
            last if system("$pager \"$output\"") == 0;
As perldoc -f system says: « If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient. »
POSIX doesn't define a notion of shell metacharacters. Looking to the Bash manual (even though sh needn't be Bash and, on Ubuntu, isn't), the notion of a shell metacharacter that it defines does not include ".
But I am reasonably sure that " is considered a metacharacter for the purpose of inducing perl to use sh -c, since the behavior the documentation describes wouldn't make sense otherwise.
On some systems, one would not see the sh -c in the output of ps as we did, because some systems use a shell for sh that performs that optimization. But in Ubuntu, we see it. As for why Perldoc.pm calls system that way, I don't know.
 
12:30 PM
I'm not quite getting it... what exactly is being checked for shell metacharacters when we run perldoc <perlsomething>?
 
Perldoc.pm has system("$pager \"$output\""), so what's being checked is the string represented by the expression:
"$pager \"$output\""
That could have been somewhat more readably written:
qq{$pager "$output"}
So $ is not part of the string, because $output is interpolated. But the " characters surrounding it are part of the string.
$pager is interpolated into sensible-pager on our systems, but you can make it expand to less if you have PAGER=less in the environment. $output is interpolated into the name of the temporary file that was created.
 
oh I see!
 
@Zanna Well it's supposed to have at least the features POSIX requires for sh. It cannot, for example, be another style of shell, like csh, and it's not supposed to be an implementation that's so old it doesn't have what POSIX requires. So substantial assumptions are safe... unless one must support very POSIX-noncompliant /bin/sh. Then lots of special effort is required. :)
 
@EliahKagan speaking of that... did you ever figure out... what you wanted to figure out?
@EliahKagan right :) I was thinking that the user could irresponsibly make a symlink /bin/sh to wherever they liked
 
@Zanna Yes. But similarly, they can make a symlink /sbin/init to wherever they like. I would expect lots and lots of other stuff to break if /bin/sh were a totally different style of shell.
 
12:41 PM
yeah, just because it can be done, I shouldn't assume that someone would actually do it other than for fun or by accident
 
I've changed what /bin/sh points to. But never by making it point to a shell that wasn't designed to be used as /bin/sh.
 
that's what I mean
 
@Zanna Sort of. I was trying to figure out why gather enough information and conceptual clarity to post a question on Unix & Linux to even be able to ask the question I would now describe as: Why are segfaults reported by different shell instances, or sometimes not at all, depending on if and how the command that crashes is run asynchronously and what shell it runs in and what shell run that shell and numerous other factors that are extremely hard to pin down?
So... as is clear from that description, what I we discovered was that it's really complicated, in part because different shells perform different optimizations when you're just running one command, or for the last command run, and ksh93 just usually avoids an actual separate process for subshells in general, and ksh93 also deliberately crashes itself when the last command a shell runs crashed...
 
...weirdly
 
...and in part as different shell authors made different decisions about whether or not redirection from the crashing command itself captures segfault messages that are sent to standard error. When combined with optimizations that are done to decrease forking, one also gets unexpected results as to whether or not redirection is effective on those messages -- as well as whether or not those messages are actually emitted -- when the redirection is performed on commands that are grouped together.
That's actually the original thing that puzzled me, and then I tried to use pipelines to test it and I discovered the pipeline weirdness that you and I worked on. The whole thing was motivated originally by my interest in being able to reply usefully to this comment:
@EliahKagan Whoops! Sorry - total jumble on my parts. I was actually using a parenthetical grouping, e.g. (./hello <1.in) &>outfile. It looks like your command (with curly-braces) works but the parentheses don't. I don't see an an explanation in the manual for why this might be the case. Any insights? — igal Nov 2 '17 at 22:19
@Zanna Sorry, do you mean people might point it to a shell that's not designed to provide /bin/sh, or that people might point it to a shell that is designed to provide /bin/sh but that might be otherwise quite different from the system's default /bin/sh?
 
12:52 PM
@EliahKagan I mean, people might point it to a shell that isn't designed to provide /bin/sh
 
Ah. Well, then they either don't know what they're doing and their system will break all over the place, or they know what they're doing and their system will break all over the place, since understanding that particular problem does not mitigate it even slightly. :)
 
they might find out some interesting stuff haha
 
1:12 PM
@EliahKagan thanks! I made an alias. I'm glad I complained to you about that issue :)
 
I'm glad, too. :)
So... about while loops in Perl... :)
The full behavior of -n and -p involves labels and continue blocks. Do you know how those work?
 
no...
 
So, with -n (from perldoc perlrun):
   LINE:
     while (<>) {
         ...             # your program goes here
     }
And, with -p (also from there):
   LINE:
     while (<>) {
         ...             # your program goes here
     } continue {
         print or die "-p destination: $!\n";
     }
 
1:32 PM
@Zanna Sorry about the delay there. I didn't mean to just drop those excerpts and walk away.
Consider this script, which runs user input as Perl code:
#!/usr/bin/env perl

use strict;
use warnings;

local $| = 1;

OWL:
for my $owl (qw(Snowy Barn Short-eared)) {
    GAME:
    for my $game (qw(Chess Checkers Monopoly Scrabble)) {
        print "$owl owl $game!\n> ";
        my $command = <>;
        eval $command;
        print "You and the $owl owl have completed a game of $game.\n";
    } continue {
        print "The $owl owl is done playing $game.\n";
    }
} continue {
    print "The $owl owl has flown away.\n";
}
That uses for rather than while, but continue blocks, labels, next, and last work the same way. The interesting commands to give to the script, when prompted, are the empty command, to just keep going, exit, which quits immediately, and:
next GAME   # skips to the continue block of the inner loop
next        # same
next OWL    # skips to the continue block of the outer loop
last GAME   # runs the continue block of the inner loop, then leaves that loop
last        # same
last OWL    # runs the continue block of the outer loop, then leaves that loop
 
@EliahKagan no problem!
when I enter next <thing>, I get some extra output about what the program is doing, like Exiting eval via next at (eval 8) line 2, <> line 8.
 
Yeah, that's normal, when you perform control flow with code that is executed by eval.
 
I would probably lose any game with any owl, except maybe Scrabble
 
:)
So, labels can be used to specify which loop next and last apply to. In Perl, next does what continue does in most languages (it probably could not be called continue because that's the word used to introduce a continue block), and last does what break does in most languages.
next is intuitively named because, after the continue block runs, it goes to the next iteration of the loop. The effect is simply to skip over the rest of the body of the loop. But last is not intuitively named, because, after the continue block runs, it doesn't go to the last iteration of the loop -- instead, the loop is done. So next goes to the next iteration, but last causes the current iteration to be the last one.
I do not know of any other languages that have continue blocks (though I imagine Perl 6, which is a different language from Perl 5, has them). So, in a sense, next and last don't do exactly what break and continue do in most languages, because most languages don't have continue blocks, but Perl does and next and last respect them.
Note that, if a loop has no continue block, then it is as though it had a continue block that was empty, and next and last immediately go directly to the next iteration or immediately break out of the loop, respectively.
Loops do not have to have labels (and in general I suggest not using them without reason). next and last work without labels, because whether or not the loop is labeled, using them with no label argument causes them to apply to the innermost loop in which they appear. When you do label a loop, the label does not have to be named like the loop variables; I just happened to do that here. It is often useful to do so but never required.
Labels and continue blocks are separate in the sense that all four combinations of having a label or not and having a continue block or not are permitted. Labels can appear elsewhere than atop a loop, because in addition to being used to let you specify which loop you want next or last to use, they can also be jumped to with goto. I recommend trying goto OWL and goto GAME at various points while running that script.
Even when the label does appear atop a loop, goto behaves very differently from next and last. It does not respect continue blocks, and if a loop appears after a label that you jump to using goto, then that loop starts over again from the beginning. It is easier (i.e., possible) to demonstrate that with for loops than with while loops.
Labels have loop-specific behavior (if one wants to attribute behavior to them rather than the code that uses them) because of next and last, but there is absolutely nothing loop-specific about goto. Many languages have goto, and programmers are discouraged from using it in almost all of them, except in situations where it is clearly more useful to use it than other flow control constructs.
Some people say that one should only use goto when it is the only option, but it's actually never the only option; however, occasionally it may be the clearest option. Usually it is not. Some programmers insist on never using goto, but there is a substantial amount of code written by experts that does use it.
However, in a language like Perl you generally need it even less than in a language like C, because Perl has sophisticated flow control constructs like continue blocks and labels that let you apply next and last to a particular loop.
Related:
Spaghetti code is a pejorative phrase for source code that has a complex and tangled control structure, especially one using many GOTO statements, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow is conceptually like a bowl of spaghetti, i.e. twisted and tangled. Spaghetti code can be caused by several factors, such as continuous modifications by several people with different programming styles over a long life cycle. Structured programming greatly decreases the incidence of spaghetti code. == History == An early reference that contributed...
To compare Perl to a couple other languages: Java has labels but no goto, and you can use break (which is like Perl's last) or continue (which is like Perl's next) with an optional label.
Similarly, Bash uses break and continue to mean the same things they mean in Java, and, like Java, Bash does not have goto. However, bash does not have labels either. Instead, in Bash, if you want break or continue to apply to any loop but the innermost one, then you can pass them an optional numeric argument to indicate the level. The higher number, the more out the loop is that is being broken or continued.
C uses break and continue to mean the same things they mean in Java (that's where Java got them), but C does not have any feature to make break or continue act on any loop but the innermost loop. However, C does have labels and goto, which are sometimes used for that purpose.
Particularly relevant is the first paragraph of the entry on goto in perldoc perlfunc (you can run perldoc -f goto to see just the entry on goto):
            The "goto LABEL" form finds the statement labeled with LABEL and
            resumes execution there. It can't be used to get out of a block or
            subroutine given to "sort". It can be used to go almost anywhere
            else within the dynamic scope, including out of subroutines, but
            it's usually better to use some other construct such as "last" or
            "die". The author of Perl has never felt the need to use this form
            of "goto" (in Perl, that is; C is another matter). (The difference
 
2:08 PM
@EliahKagan back to the start of the loop!
@EliahKagan sometimes when I am marking a physics exam (it's done online through an awful java applet which gets harder for me to use in Firefox every year) there is a math question with 3 or 4 available marks, and I try to relieve the boredom by writing a sort of pseudocode algorithm to mark the question for me (which I can't actually implement at all - I still have to mark the paper). Once I showed one of my efforts to my brother and he admonished me for using GOTOs haha
 
What was the algorithm, such that you were tempted to use GOTO?! :)
 
haha I looked for it, but I don't think it's something I saved between installations...
 
It seems to me that what I have told you about last contains a severe error! I am trying to figure out why I said that last "respects" continue blocks. next certainly does. But last skips over them; it breaks out of the loop immediately. The purpose of a continue block is to run before each time the loop continues, that is, before any iterations of the loop that begin after a preceding iteration has finished.
Interestingly, I tested that script I showed you, and tried this all out with next and last, yet still managed to stated it incorrectly after doing so!
 
2:25 PM
The aim is to exit as quickly as possible. In the simplest case, the student wrote nothing, so we can award 0 and exit. The second simplest case is where they wrote the correct answer on the answer line, in which case we can award $max and exit. In between, there are possibilities that are interdependent. Like if they substituted the values wrongly, but transposed the variables correctly, they get a mark for one but not the other...
 
So that message contains wrong information because it says "after the continue block runs" but the continue block belonging to the loop to which last is applied does not run in the case of last. (The claim that next is intuitively named and last is not, as well as the description of the behavior of next, is still correct, however.)
 
but you can't tell that they did the right transposition with the wrong substitution unless you can see what they thought the values of the variables were... anyway, I am wandering from the subject!
 
That message is wrong, because for last, it incorrectly says, "runs the continue block..."
I am sorry about this repeated error. However, I am pleased to have figured out the problem: I actually held a totally wrong belief about what last actually did. I don't think I have ever written a loop with a continue block in which I used last, so my wrong belief was never corrected until now.
So here's the corrected version of that... with information about redo included as well. I had omitted redo before to better facilitate my comparison to other languages including Bash (which don't have redo--I don't know of languages other than Perl that have it). However, my goal of making that comparison without being confusing has failed as a result of the serious error that I repeated many times and must correct. So I might as well say what redo does, now. :)
next GAME   # skips to the continue block of the inner loop
next        # same
next OWL    # skips to the continue block of the outer loop
last GAME   # leaves the inner loop
last        # same
last OWL    # leaves the outer loop
redo GAME   # goes back to the beginning of the inner loop's current iteration
redo        # same
redo OWL    # goes back to the beginning of the outer loop's current iteration
You can try giving redo, redo GAME, and redo OWL to the script.
This message is partly wrong because, unlike next, which respects continue blocks, last skips over them, and thus last really does do the same thing break does in other languages.
This message is correct but potentially misleading, or at least confusing, because the behavior of last in the absence of a continue block is the same as its behavior in the presence of any continue block, not merely an empty one. The behavior of next in the absence of a continue block, however, is only equivalent to the behavior of next in the presence of a continue block that is empty.
This message is slightly wrong or at least misleading, because while goto is indeed very different from both next and last, the behavior of goto not respecting continue blocks does not distinguish it from last (nor from redo, which I had not yet mentioned; only next jumps to the continue block; last and redo don't).
I believe the rest of what I have said is correct. If someone ever writes an answer (or anything) based on what I said here, I hope they notice these corrections to a significant portion of the recently preceding material; without these corrections, that material was significantly in error with respect to how last behaves, and remains that way because I cannot edit those messages. (They could be moved, but I don't want that, nor for them to be deleted. That'd be even more confusing.)
@Zanna Also, sorry!
@Zanna It sounds to me like what you wanted was to write a function (or "subroutine," in languages that call them that, such as Perl), and return from the function in all the places you had used GOTO.
 
2:49 PM
@EliahKagan agreed :)
 
Most programming languages (that have subroutines/functions) let them communicate their result by returning it. Bash is an exception; this is only occasionally practical, because what you return from a function in bash with the return builtin must fall in the allowed range of exit statuses, and you are best off avoiding at least half that range -- the upper half -- since it's what the shell uses to indicate the various signals that may have crashed the last command in the function that ran.
And they must, of course, be numeric. Often the result one would want to return is a string, or something. So in practice, the two common ways to return information from a function in Bash are to have it print it, and then use the function in subshell that accesses its output, for example by calling the function inside command substitution or in a pipeline; and to have the function write its result somewhere that it can later be read. This is rare for programming langauges.
It's more common to have a programming language whose subroutines can never return a value and must always stash it somewhere (old languages in the BASIC family) or to not have subroutines at all (assembly languages and a number of esolangs) than to have the situation of Bourne-style shells like Bash where functions return values but they are like the limited values programs can return when they exit.
 
3:17 PM
@Zanna So, as an example of a subroutine in Perl that uses early return to good effect (though it could certainly be implemented without it):
#!/usr/bin/env perl

use strict;
use warnings;
use Math::BigInt;

# This is a demonstration. There is no actual need to implement exponentation
# for BigInt, because ** supports it. This technique is often useful, though,
# as it works for implementing exponentiation one one's own data types. For
# example, this algorithm is commonly used to implement the operation of
# raising a square matrix to a power, when one has implemented matrix
# multiplication.
sub pow {
    my ($base, $expt) = @_;
    $expt >= 0 or die "negative exponents are not supported\n";
Bugfix (though the bug didn't affect the program's behavior much, as far as I know) -- the exponent should just be a regular number, not a BigInt:
#!/usr/bin/env perl

use strict;
use warnings;
use Math::BigInt;

# This is a demonstration. There is no actual need to implement exponentation
# for BigInt, because ** supports it. This technique is often useful, though,
# as it works for implementing exponentiation one one's own data types. For
# example, this algorithm is commonly used to implement the operation of
# raising a square matrix to a power, when one has implemented matrix
# multiplication.
sub pow {
    my ($base, $expt) = @_;
    $expt >= 0 or die "negative exponents are not supported\n";
 

« first day (135 days earlier)      last day (2264 days later) »