[SOLVED] ps conflicting options

dizwell · 2019-05-29 09:45:27

Hello. I've been doing "ps -ef | grep something" since about 1996 on assorted Unix-y/Linux-y systems without drama. But in a fresh Arch installation, I'm being told that this is an "error: conflicting format options".

On CentOS 6, for example:

[hjr@oracledb ~]$ ps -ef | grep ora
hjr       2988  2971  0 10:32 pts/0    00:00:00 grep ora

On FreeBSD:

[hjr@jsb ~]$ ps -ef | grep TERM
31387  0  Ss   0:00.01 USER=hjr LOGNAME=hjr HOME=/home/hjr MAIL=/var/mail/hjr PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/hjr/bin TERM=xterm-256color BLOCKSIZE=K

But on Arch:

[hjr@britten ~]$ uname -a
Linux britten 5.1.4-arch1-1-ARCH #1 SMP PREEMPT Wed May 22 08:06:56 UTC 2019 x86_64 GNU/Linux
[hjr@britten ~]$ ps -ef | grep TERM
error: conflicting format options

Usage:
 ps [options]

 Try 'ps --help <simple|list|output|threads|misc|all>'
  or 'ps --help <s|l|o|t|m|a>'
 for additional help text.

For more details see ps(1).

But when I do what the error message says and read the ps(1) manual on my Arch box, I see this:

EXAMPLES
       To see every process on the system using standard syntax:
          ps -e
          ps -ef
          ps -eF
          ps -ely
          ...

...which seems to indicate that "ps -ef " ought to be valid! Since '-e' simply means "list all processes" and '-f' means "Do full-format listing", I can't see logically why these options would be in conflict with each other in any case!

Can anyone explain why Arch is behaving in this way, please? I can live with it and work around it, but I am curious to know why Arch (with which I have limited experience) is behaving so very differently to every other Linux, BSD and Unix system I've worked with in the past 20 years :-)

Thanks in advance!
Regards
HJR

Last edited by dizwell (2019-05-29 11:27:24)

Awebb · 2019-05-29 10:44:31

It works on all my Arch boxes. I cannot reproduce the error.

1. which ps
2. pacman -Qo /usr/sbin/ps
3. pacman -Qi procps-ng

EDIT:

4. Scan your bashrc's and profile files for an alias accidentally or even voluntarily modifying ps.

Last edited by Awebb (2019-05-29 10:47:26)

seth · 2019-05-29 10:59:33

To shortcut Awebb's first and last point:

type ps

Last edited by seth (2019-05-29 10:59:58)

dizwell · 2019-05-29 11:00:32

Thanks for the speedy reply, Awebb. I think all your suggestions were excellent, but your fourth one nailed it!

[hjr@britten ~]$ cat .bashrc
#
# ~/.bashrc
#
PS1='[\u@\h \W]\$ '

if [ -d "$HOME/.bin" ] ;
        then PATH="$HOME/.bin:$PATH"
fi

[...]
#ps
alias ps="ps auxf"
alias psgrep="ps aux | grep -v grep | grep -i -e VSZ -e"
[...]

I see someone has "helpfully" aliased ps to something that comes with a bunch of pre-configured options. And it doesn't surprise me that the ones I want to specify might conflict with those already chosen for me!

Problem solved. I am of course now kicking myself that I didn't think to look for aliases in the first place!

Much obliged. That particular bit of helpful-ness has now been excised and all works normally as before!

Thanks very much
HJR

Last edited by dizwell (2019-05-29 11:01:04)

Trilby · 2019-05-29 11:05:11

dizwell wrote:

I see someone has ...

Someone? A rouge hacker broke into your system and added a couple aliases to your bashrc? Or is this not actually an arch linux system?

dizwell · 2019-05-29 11:14:15

"Rouge"? No, he wasn't wearing makeup.

He wasn't a rogue hacker, either. It was a colleague who sets things up the way he likes, and doesn't always tell me when his choices don't align with mine :-)

seth · 2019-05-29 11:16:46

You're aware that this is a multi-user system. Each of you can and should have an account of his own.

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

dizwell · 2019-05-29 11:25:25

I will edit the subject line as indicated.

Meanwhile, everyone does have an account of his own, but that doesn't stop a sysadmin with root access doing things to a user's .bashrc which he thinks will be helpful/useful to them.

seth · 2019-05-29 11:31:40

No, but https://en.wikipedia.org/wiki/Brass_knuckles will.
Admins have no business editing your local configs because "they feel like". If they don't understand why, they've no business being admins.

dizwell · 2019-05-29 11:48:12

Well, I don't want to get into a long discussion on the matter, because it's not germane to the original question, but as a system and database admin myself over many years, I have often set things up for users in what I consider to be a 'useful' way, fully understanding that the user can then alter that configuration to suit themselves afterwards. In my DBA past, I would often set up user accounts for my juniors with an alias of 'sql' to 'rlwrap sqlplus', for example, because having the option for a command line history within SQL*Plus is damned useful (but note that my alias didn't mean the original command was altered in meaning, but simply gave them an alternative way of invoking SQL*Plus that would give them the functionality if they remembered to invoke SQL*Plus with the modified command).

The fault on this occasion was mine, for not even considering that something as 'fundamental' as "ps" would have been aliased, not the admin's for wanting to get people consistently using his preferred way of listing processes!

Last edited by dizwell (2019-05-29 11:49:39)

Awebb · 2019-05-29 15:07:13

seth wrote:

No, but https://en.wikipedia.org/wiki/Brass_knuckles will.
Admins have no business editing your local configs because "they feel like". If they don't understand why, they've no business being admins.

And then there is /etc/skel and the whole story is just another day in in an actual multi-user environment. Probably nothing to see here.

seth · 2019-05-29 15:09:00

There's a difference between pre-fabbing stuff and editing it at will any time afterwards as I found implied by post #8

Arch Linux

#1 2019-05-29 09:45:27

[SOLVED] ps conflicting options

#2 2019-05-29 10:44:31

Re: [SOLVED] ps conflicting options

#3 2019-05-29 10:59:33

Re: [SOLVED] ps conflicting options

#4 2019-05-29 11:00:32

Re: [SOLVED] ps conflicting options

#5 2019-05-29 11:05:11

Re: [SOLVED] ps conflicting options

#6 2019-05-29 11:14:15

Re: [SOLVED] ps conflicting options

#7 2019-05-29 11:16:46

Re: [SOLVED] ps conflicting options

#8 2019-05-29 11:25:25

Re: [SOLVED] ps conflicting options

#9 2019-05-29 11:31:40

Re: [SOLVED] ps conflicting options

#10 2019-05-29 11:48:12

Re: [SOLVED] ps conflicting options

#11 2019-05-29 15:07:13

Re: [SOLVED] ps conflicting options

#12 2019-05-29 15:09:00

Re: [SOLVED] ps conflicting options

Board footer