« first day (3026 days earlier)      last day (1922 days later) » 

4:52 AM
@JeffSchaller Perhaps you are making ed more popular. Soon it will make a comeback!
 
 
3 hours later…
7:25 AM
Quick question guys. Is 2>&1 > details.txt intended to display the error on the screen as well as redirect STDOUT and STDERR to details.txt? If yes, it doesn't appear to work although 2>&1 | tee details.txt does. Why is that?
 
No, it isn't
 
@MichaelHomer What do you mean by it isn't?
@MichaelHomer - The post (unix.stackexchange.com/a/20472/321547) suggests it does.
 
@Motivated I mean to answer your (first) question
 
@MichaelHomer So what does 2>&1 > details.txt achieve?
 
That answer does suggest that tee will work for that, which I think is what you're saying you saw (right?)
 
7:32 AM
@MichaelHomer Yes tee does work however i'm unclear to the purpose of 2>&1 > details.txt
 
send standard error and standard output to the log file
 
@MichaelHomer That's what i thought i.e. redirect STDOUT and STDERR to details.txt
@MichaelHomer If i run a simple test of ll /root/ 2>&1 > details.txt, the file is empty. If i run the command ll /root/ 2>&1 | tee details.txt the output is ls: cannot open directory '/root/': Permission denied. The file captures it as well.
 
It should be ll /root > details.txt 2>&1
That is a weird question/set of answers
The top answer is just wrong
And the others are confused
This answer seems to be correct but a bit unclear:
7
A: Difference between 2>&1 > output.log and 2>&1 | tee output.log

osgxFirst command will do the another task: After 2>&1 > output.log the old STDOUT will be saved (copied) in STDERR and then STDOUT will be redirected to file. So, stdout will go to file and stderr will go to console. And in 2>&1 | tee output.log both streams will be redirected to tee. Te...

I'm sure we have a canonical question about this somewhere but it's not the one I thought it was
 
8:25 AM
@MichaelHomer Thanks. Yes, it's unclear. It would be great to have a clear answer.
 
I thought it was this one, but it doesn't seem to address them much at all
211
Q: What are the shell's control and redirection operators?

terdonI often see tutorials online that connect various commands with different symbols. For example: command1 | command2 command1 & command2 command1 || command2 command1 && command2 Others seem to be connecting commands to files: command1 > file1 command1 >> file1 What are these things?...

 
@Motivated Redirections are processed in a left-to-right order. This means that "2>&1 > details.txt" will first redirect the standard error stream to wherever the standard output stream is going, and then redirect standard output to a file. The standard error stream will not be redirected to that file.
 
The one you commented on is also right, but also a bit confusingly written
It's too late to reject this migration but it is a bit of a problem to have that question lying around
 
Since standard error and output are both going to the console by default, and assuming no redirections of either stream happens before or after this (for example through a later pipe), this would have the same visible effect as ">details.txt".
 
@Kusalananda These messages would make a good answer to the question and much improve on what's there
 
8:34 AM
Haven't seen the question. I'll look.
 
This one:
28
Q: Difference between 2>&1 > output.log and 2>&1 | tee output.log

Chander ShivdasaniI wanted to know the difference between the following two commands 2>&1 > output.log and 2>&1 | tee output.log I saw one of my colleague use second option to redirect. I know what 2>&1 does, my only question is what is the purpose of using tee where a simple redirection ">" operator can ...

@Motivated Here you go:
1
A: Difference between 2>&1 > output.log and 2>&1 | tee output.log

KusalanandaRedirections are handled in a left-to-right manner. utility 2>&1 >output.log Here, the standard error stream would first be redirected to wherever the standard output stream goes (possibly to the console), and then the standard output stream would be redirected to a file. The standard error ...

 
9:41 AM
@MichaelHomer Just goes to show that I should start looking more at old questions, even if they are accepted.
 
10:22 AM
Hi everybody! @Kusalananda Do you think it would be possible to better define "wherever the standard output stream goes"? (I'm of course referring to unix.stackexchange.com/a/495731/315749)
E.g. On my system I can run cat - and see that /proc/<pid of cat>/fd/1 is a symbolic link to /dev/pts/1, while if I run >somefile cat - I can observe that /proc/<pid of cat>/fd/1 is a symbolic link to /path/to/somefile. In this context it looks like 2>&1 cat - means "link cat's file descriptor 2 to what now cat's file descriptor 1 is linked to".
This may be inaccurate and/or not general, or even outright wrong... but I feel this kind of example would help understanding what redirection does.
 
@fra-san if you have comments on a specific post, IMO it’s better to comment on the post directly rather than in chat: it means that other readers will see the comments, and also that the person you’re addressing can find the comments more easily.
 
@StephenKitt I agree, I just felt my comment would have been too long and noisy to be appropriate as a comment to the answer. I will see if I can shrink it and make it useful there.
 
@fra-san I don't know much of how Linux handles /proc/pid/fd stuff. You may want to ask a new question.
 
@Kusalananda OK, thanks!
 
 
2 hours later…
12:48 PM
Hello. CentOS 7.5, gpm not installed, but mouse works in jed, mc, micro, tmux, htop, etc. yum list installed | grep gpm says gpm-libsis installed. Is this enough for the mouse support? I thought gpm daemon was needed for mouse support. Thank you for any info.
 
@data in a terminal emulator, or on the console?
 
1:09 PM
@StephenKitt not sure what you mean. XShell ssh connected to local CentOS (WSL on Windows 10), ssh connected to remote CentOS
 
1:22 PM
Weirdest git commit message today at work: "we need a library for canonicalization of smiles"
It probably makes more sense if one knows what a "smile" is.
 
1:38 PM
@data OK, so it’s probably your local terminal interpreting mouse clicks and sending the corresponding xterm codes to the target, no gpm required in that case
 
Comments from Perl users? See particularly the most recent comments - github.com/plk/biber/issues/247 . This isn't terribly important, but does strike me as a bit odd.
@StephenKitt Are you a Perl user? @derobert, @terdon I know you are Perl users.
 
@FaheemMitha I used to be, not so much nowadays but it does happen.
 
@StephenKitt Ok. Well, if you feel like offering an opinion...
 
@FaheemMitha it seems to me you could try patching Biber to not require 5.26, and adjust the Debian package likewise — its unit test coverage seems to be comprehensive enough for the resulting package to be trustworthy (if everything passes).
 
@StephenKitt If I had any idea how to do so, I might. Did I mention I'm not a Perl user?
 
1:48 PM
@FaheemMitha it boils down to reverting github.com/plk/biber/commit/… AFAICT.
 
@StephenKitt Surely that's not the only reason for requiring 5.26. That commit basically just renames everything. And did you see my last comment about Perl libraries?
If you want a better sort algorithm (or whatever it is), do you really need to upgrade Perl from 5.24 to 5.26?
 
@FaheemMitha You can't be right about the perl version. 2.26 is veeeery old. You should have 5 point something.
 
@terdon Sigh. Sorry, I keep doing that.
 
@FaheemMitha as dcpurton says, you need to wait for plk’s input for the reason to use 5.26. If the requirement is on a base module, you need to upgrade Perl, not just a library.
 
And by renames everything, I mean just renames the version number.
@StephenKitt Is Perl 5 still evolving significantly?
@StephenKitt Well, if he replies. He's replied exactly once, at the start of the thread.
 
1:52 PM
Not between minor revisions. I really doubt that upgrading perl from 5.24 to 5.26 will break anything.
 
@FaheemMitha I’m not sure, but in Debian base module bumps are distribution-wide.
 
I can understand why Debian doesn't want to distribute a binary. They would be embedding Perl, which is a no-no.
 
@FaheemMitha I realise that, which is why I suggested going for the downgrade and relying on the unit tests to catch any resulting regressions.
 
@terdon My question was whether one gains anything from going from 24 to 26.
 
But I don't understand the issue. What are the actual relevant versions?
 
1:53 PM
@StephenKitt I actually tried that. And all the unit tests failed.
But it might be some configuration issue. It seems unlikely that a downgrade would break everything. I haven't investigated the unit tests. The maintainer is a little... volatile and emotional, which is why I haven't asked him already. Maybe he's stressed.
 
@FaheemMitha The new features in .26? I'm saying they won't be very big differences. But can you please check your script and tell us what the actual versions are? You say "Biber requires Perl 2.26, and the version in Debian stable is only 2.24" but even if I assume you mean 5.24 and 5.26, you then show a perl script that requires 5.24 and not 5.26
 
I imagine packaging TeX Live is an onerous and thankless task. I'm not even sure why he keeps at it.
@terdon Everywhere I've written 2.x, please assume 5.x.
Sorry, it's my dyslexia, or something.
 
@FaheemMitha Yes, but in your script you show use v5.24; which is the version you say is already installed, so why is there an issue?
Does the script actually have use 5.26 and not use 5.24?
 
@terdon That latter part isn't my fault. I'm just quoting the script. I assume you are talking about the beginning part of the script, right?
 
Yes
 
1:56 PM
@terdon That's the dependency that the package is declaring. One sec, I'll double check.
 
If the script asks for v5.24 and that is what you have installed, what makes you think this is an issue?
 
Ok, I'm looking at the source for Biber 2.12.
The bin/biber script contained therein starts with:
#!/usr/bin/env perl

use v5.24;
use strict;
use warnings;
 
OK. So it is asking for the version you already have. Who is asking for 5.26?
 
Well, that's because I changed it.
 
Great. So why do you think there's a problem? (and who's control?)
@FaheemMitha wait, what?
 
2:02 PM
@terdon Check apt-cache showsrc biber and see the Build-Depends for 2.12.
@terdon I changed 2.26 to 2.24 to try to get it to build. Basically what @StephenKitt was suggesting.
The Build-Depends for 2.12 includes perl (>= 5.26).
 
ah
 
@terdon Sorry if I am being confusing.
the value in debian/control was changed by me, so I should not have quoted it.
 
I see. Well, anyway, the chances of breaking anything by upgrading from one minor revision of perl to another are minimal to nonexistent.
 
@terdon Actually, we're talking about a downgrade here.
 
Perl changes are always backwards compatible as far as I know.
@FaheemMitha We are? I don't understand. You said that "The Build-Depends for 2.12 includes perl (>= 5.26)." but you have 5.24 installed.
 
2:05 PM
Basically, the question is whether the maintainer is making use of any new features from 5.26 or is upgrading the Perl requirement for no good reason.
 
> Biber requires Perl 2.26, and the version in Debian stable is only 2.24
 
@terdon Yes, I would like to use a package with Perl 5.24 that has a declared dependency on 2.26. That's normally considered to be a downgrade.
@terdon Correct, 2.12, that is.
 
2.12?
 
Anyway, it might be worth checking the unit tests and seeing why they fail.
@terdon Biber 2.12.
 
Can we please keep Biber versions out of this? it's confusing enough already :)
 
2:07 PM
It seems unlikely that a downgrade would have broken every test. @StephenKitt, what do you think?
@terdon Ok. Sorry.
 
Faheem, if it requires 5.26 and you have 5.24 installed, then you need to upgrade perl to 5.26, why would you call that a downgrade?
And no, upgrading perl to 5.26 is extremely unlikely to cause any issues.
 
@FaheemMitha yes, it’s unlikely.
 
@terdon It's a downgrade for Biber. Upgrading Perl isn't on the cards.
 
@FaheemMitha Why not?
 
@terdon because Faheem is downgrading the build-requirement from Perl 5.26 to 5.24.
 
2:09 PM
That seems like the simplest solution
 
@terdon Really? I'm reluctant to take that chance.
@terdon As a rule of thumb, messing with base packages is a no-no.
 
@terdon in Debian, upgrading Perl == upgrading the distribution...
 
@StephenKitt Yes, exactly.
@StephenKitt Exactly. Which can lead to interesting outcomes down the road, even if not immediately.
 
@StephenKitt Ah, long dependency chains. OK.
 
I mean, I could rebuild Perl 5.26 for stable, and then install it, but that just seems like asking for trouble. @StephenKitt, do you concur?
 
2:11 PM
@FaheemMitha yes, it most definitely does.
 
You could always install it separately
 
@StephenKitt I'll go back and look at the Biber unit tests.
 
16
Q: How should I install more than one version of Perl?

Brad GilbertI want to install, from source, Perl versions 5.005, v5.6, v5.8, v5.10 Right now I have 'v5.10.0' installed. /opt/perl/bin /opt/perl/html /opt/perl/lib /opt/perl/man /opt/perl/lib/5.10.0 /opt/perl/lib/site_perl /opt/perl/lib/site_perl/5.10.0 Will I have any problems if I install them all i...

 
Do you agree that a downgrade to 2.24 should not have broken everything?
@terdon Yes, I could do a local install.
But that would mean I couldn't use the Debian Biber package.
 
No, you'd have to edit it to use the right version
 
2:12 PM
I'd have to do a local install of Biber too.
 
Well, that's what you get for using Debian stable :P
 
@terdon Having a system package depend on a local package is a violation of Debian policy.
@terdon Not helpful.
Also, probably a bad idea. Debian Policy is just codified best practice.
@terdon Anyway, thank you for taking the time to share your thoughts...
I suppose this is at least marginally on-topic here. Even if it is about TeX.
 
Seems completely on topic, really. It's about installing software and dependency hell.
Joking apart, why do you use stable instead of testing?
I wouldn't go for stable unless I was building a server.
 
@terdon Not that hellish, really. At least, it wouldn't be if the Biber maintainer didn't insist on moving the goalposts.
@terdon I've used Debian stable since 2001. It's worked well for me.
I'm not that sure about testing.
I know quite a lot of Debian people use Debian unstable. Apparently it's often (usually?) in better shape than testing.
 
@FaheemMitha the reason Debian people use unstable is that that’s where development happens
 
2:17 PM
None of this is really that important. My use of Biber is also quite marginal. It's just that one wants to get everything sorted...
 
It’s much easier to maintain your packages if you do so on unstable.
 
@StephenKitt Well, that too. But isn't unstable often in a more consistent state?
I'e head that testing can often be out of sync because packages take time to trickle in.
 
@FaheemMitha unstable has no consistency guarantees; that’s what testing is for.
 
@StephenKitt Oh? I guess maybe I have it backwards.
Well, need to go for dinner. I'll take a second look at the Biber unit tests when I get back.
 
@FaheemMitha consistency and “up-to-dateness” are different things.
 
2:19 PM
@StephenKitt I realise that.
 
I strongly recommend testing. It's a decent compromise between stability and up to date packages.
Stable is often really old.
 
3:06 PM
@terdon Just to expand on my previous response. I've found stable works well for me, for a long time. Once things were changing sufficiently fast that one felt really behind using stable. But it's not like that these days. And most things one is interested in are leaf packages, anyway.
So they are often/usually trivial to backport if you want to do so, even complicated stuff.
@terdon I thought you used Arch.
 
3:26 PM
@FaheemMitha I do, but I have used various others over the years. Including Mint Debian which is basically testing with a couple of extras.
 
@terdon I see.
 
3:51 PM
@Kusalananda Thanks for clarifying that Kusalananda.
@Kusalananda Could you further clarify what you meany by "assuming no redirections of either stream happens before or after this (for example through a later pipe), this would have the same visible effect as ">details.txt".?
 
@terdon A snapshot of testing, presumably. Not really the same as Debian testing, which is a moving target.
 
 
2 hours later…
5:38 PM
@FaheemMitha No, no snapshot. It's testing with a couple of extra tools. They use the exact same repositories and everything.
 
5:48 PM
@Fabby I ended up backing up my files and deleting my user, then recreating it. I added files back into my new /home directory incrementally to determine what breaks stuff, and it looks like it was my .bashrc or .bash_profile. It works now.
Thank you for your help! I didn't think of making a new user to test.
 
6:35 PM
@Motivated That's what I try to show in the second half of my answer to that question.
 
 
1 hour later…
7:40 PM
@FaheemMitha you could check perl5260delta to see what changed in perl 5.26.0
perldoc.perl.org/perl5260delta.html looks like an online copy
perldoc.perl.org/… sees like the only sorting change that might matter.
 
 
2 hours later…
9:20 PM
@terdon So a rolling release?
If that is what they are calling it these days.
@derobert The question is whether the maintainer actually made any backward breaking changes.
 

« first day (3026 days earlier)      last day (1922 days later) »