such an error is due to head closing reading before ls is done writing. It’s not really a problem, just an annoying error message. If I
type
ls 2>&1 -lt /etc/ | head
then the error message does not appear. Also, if I login directly to the root account, either remotely or with
ssh root@localhost
then the Broken pipe error message does not appear either. So, it seems to be due to the combination of tcsh and su to root (bash). Is there any way to troubleshoot it?
I also want to mention that I am familiar with sudo, but I prefer su.
And please in the future use CODE tags around copied/pasted computer text in a post. It is the # button in the tool bar of the post editor. When applicable copy/paste complete, that is including the prompt, the command, the output and the next prompt.
My guess is that hardly anybody here still uses 13.2, so not able to reproduce your issue. Reporting a bug is useless too, unless you can proove that the issue exists in supported versions.
IMNSHO this issue isn’t your biggest. Running an outdated OS is.
My 2 cents
I just tried this with Leap 15.0. And I am not seeing the “problem” there.
I doubt that it is specifically due to “tcsh”. It more likely has to do with whether the root shell is a login shell or a secondary shell (but I’m guessing).
Here’s my suggestion:
After
su
try running
exec tcsh
That way you will be using “tcsh” as root. That’s what I normally do, mainly because I am less likely to make dumb mistakes in “tcsh” than in “bash” since “tcsh” is what I mostly use. And, in my opinion, it is wiser to use the shell in which you are less likely to make mistakes.
I don’t guarantee that this will solve the “broken pipe” problem. However, “tcsh” handling of child processes and pipes is different from “bash” handling. So you might get a different result.
I normally use “csh” here (which is really “tcsh”). I don’t recall running into that problem. But then I normally don’t run “ls -lt | head”. I’m more likely to run “ls -lt | less”.
Thanks. I don’t get the error message if I start “tcsh” after “su”. I wonder whether it’s worth it or safe to simply set the root shell to “tcsh”. It’s a minor annoyance since I rarely browse through folders as root. However, I was curious whether there is a way to troubleshoot this error message.
It’s also nice to hear about other people using “tcsh” (or “csh”) as their default shell. I always thought that redirection is simpler in “tcsh”, although you have more options in “bash” but I was never in a situation where I needed them.
I think that’s unwise. There is probably software that assumes the root shell is “bash” or “sh”.
What I do is create a user with name “croot”, home directory “/croot” and with “/bin/csh” as shell. It’s basically a copy of the root entries in “/etc/passwd” and “/etc/shadow” with the obvious changes (name, shell and home). And then I can “su croot” to get to that account. However, you will find opinions that this is a bad idea. People differ over that. It has been working fine for me since forever (BSD 4.3, ATT SystemV, Solaris, Slackware, RedHat, openSUSE, and others).
It’s a minor annoyance since I rarely browse through folders as root. However, I was curious whether there is a way to troubleshoot this error message.
There really isn’t anything to troubleshoot. And perhaps I do see the message but just don’t notice it because I’ve learned to ignore spurious “broken pipe” messages.
It’s also nice to hear about other people using “tcsh” (or “csh”) as their default shell.
There are others, though I don’t know who they are. Occasionally an update will make a mistake in “/etc/csh.cshrc”, and then a bunch of “csh” users will participate in the bug report and discussion.
In the past “tcsh” and “csh” used to differ. “tcsh” had the ability of using the arrows to navigate to a previous command while “csh” did not. This was under Solaris in the late 90s. I got stuck calling the configuration file “~/.tcshrc”, although in a script I still invoke “csh”. Today in openSUSE “csh” is a symbolic link to “tcsh”, but the global configuration files are called “/etc/csh.*”.
Yes, the original “csh” came from Berkeley, and “csh” in Solaris was based on that version. As far as I know, “tcsh” has always use “/etc/csh.cshrc” and “/etc/csh.login” as its startup files. It was meant to be an open source replacement for the original “csh”. In most linux system, “csh” is just “tcsh” (or a link to “tcsh”). But I’m not sure whether they behave the same. Somehow I have the impression that the program checks whether it was called under the name “csh” or the name “tcsh” and modifies its behavior accordingly.
As for history – “csh” has had history capabilities for as long as I can remember. However, it was probably only with “tcsh” that you could use the arrow keys to access that history. I never use that ability myself.
did not help in this case, my strong advice is to use it and not plain su, specially when using it “to become root”. Not having the environment of root when doing things as root might have security implications.
I have always felt very confident to keep using an installation of SuSE and openSUSE for a long time after its official support has expired. I have always found openSUSE (former SuSE) distributions very stable and reliable.
Interestingly, I have only recently discovered that with “tcsh” you can use “Alt+P” or “Alt+N” to navigate history. These are some of the reasons why I like to stay with “tcsh” instead of switching to “bash”. I have always found “bash” “Ctrl+R” to recall history a bit clunky.
A while ago, I tried switching to “bash” for scripting, but I discovered that “bash” is not equal “bash”. A “bash” script that ran on openSUSE would not run on fedora because the latter did not have all the extensions as openSUSE’s “bash”. That was 12 years ago, so it might have changed now. But it was enough to make me want to stay with “csh”.
I mostly use “sh” for scripting. Yes, it is actually “bash”, but I try to stick to what works in the traditional Bourne shell for maximal compatibility.
Well, as long as you are not connected to the internet and don’t have user population of students, you may be save. But there are other considerations, like you have now, asking for help on a version nobody else has. That may work when the problem is very general, but for the rest people can not recreate your problem to play around with it, etc. And I have seen others that had very old and thus very stable systems, that got under pressure for some reason to install additional software. They had to report back that they first had to upgrade skipping several versions.
