PP-483: As a user or admin, I would like qstat to return a full job attribute list with 1 line per job attribute, so that I can more easily use tools like grep to find the information I am looking for regarding my jobs


#1

I have posted a EDD ( https://pbspro.atlassian.net/wiki/pages/viewpage.action?pageId=31621169 ) for the proposed changes to qstat to allow qstat -f to return each attribute on a single line. Please review and provide feedback.


#2

Hi Jon,

If qstat had a JSON output flag, it would make parsing the output much easier. It would be a simple matter to write a wrapper around qstat to present the output in any format the site or user desires. Adding “-1” as a new parameter makes sense when you look at the “ls” command, but is rather limited in scope. Also, does “-1” also apply to things like the environment variable list? With JSON output, we wouldn’t have to answer those types of questions.

I don’t care for the 78 character line limit. The days of physical Wyse and VT100 serial terminals are long behind us. Trust me, I used them back in the day. :nerd:

Fortunately, “qstat -j” hasn’t been used yet.

Thanks,

Mike


#3

Also, could you provide some sample output in your interface description?

Thanks,

Mike


#4

That is another user story that we plan to work on. It’s ticket number is PP-484.

I have added the sample output to the EDD


#5

The below command might be useful work around ( i use it )

qstat -f jobid | column -t
qstat -f | column -t


#6

If environment variables are also included here, keep in mind that if the value contains newlines (\n), that will still break the output.


#7

I tested this out with my prototype and it works as expected and does not break the output for the environment variables with \n in them.


#8

I’d love to see this. For now, I use a hack/wrapper, as described in

Qstat -f <JOBID> line breaks

The column approach for sure does not work for me.

That is a good point. It may actually be considered to remove/replace such newlines before writing the output (to ensure that it goes on a single line).

/Bjarne


#9

Hi Jon,
This page is not accessible. Can you update the link if you have moved the page?


#10

It would also be useful if we could do a wide output that did not cut off the job name if it was longer then the 15 or so characters when I do a qstat -aw.


#11

It looks like the page was restricted some how. It is now no longer restricted.


#12

FYI:
I tried this , this works great
qstat -f | column -t -x -c 20


#13

Hi Jon,
I don’t get what’s the use of adding an additional option whose effect will be visible only when certain attributes values is greater than 78 characters. If none of the attributes have value greater than 78 character , the output for both qstat -f and qstat -f1 will be same. To me -1 doesn’t look very meaningful either, since attributes are already shown in new line.

I feel we should extend -f option to accept an optional argument like “pretty” or “wide” and keep one of them as default. Where option “pretty” will trim and add new line to values greater than 78, whereas option “wide” will not.

Adding an option like -1 gives an idea that it can be used with other existing option of qstat, which I don’t think is intended in this requirement otherwise it should be added in the EDD.

eg. like what happens if user runs : qstat -1 job.id.

Regards
Dilip


#14

Hi @dilip-krishnan,

This option will be helpful while parsing the job information. You can refer this link in the forum where the same requirement is demanded. The question of -1 over other options is debatable. But I would prefer -1 as list command uses this.(ls -1).
-1 list one file per line (from ls man page)
Our requirement is similar to this as we list one job attribute per line.
The EDD also explains that "-1" is used in conjunction with "-f".


#15

Hi @nithinj,
I understand the requirement and it’s importance. And my understanding is that we want to provide user
qstat -f output without word wrapping. As per convention -1 option prints related information in single line hence this can misguide the user, since user can expect output of “qstat -f1” to print each individual job and its related information in a single line.

In general -1 option in command is for single line and not for word wrapping. If we use -1 with “qstat -f” to addressed this requirement, then it will be inconsistent with existing behaviour of “qstat -s1” and “qstat -n1” ( which print each job related information in single line) and other linux commands like ls,dir.

I feel better approach would be to extend existing -f option of qstat, to accept an argument to avoid word wrapping.
eg. “qstat -f wide”


#16

I think that is a good suggestion, since -1 does indeed already have a different meaning for other qstat options. Rather than “wide”, though, what about using the existing “-w”? Currently qstat -fw has no official function (it is not shown as a supported combination of options in the usage). In practice it appears to produce the same output as qstat -aw.


#17

Hi Scott,
qstat -fw is not documented, but existing implementation doesn’t throw usage error when qstat -fw is used. So
I am not sure if that is expected behaviour or a bug.

But yeah qstat -fw looks more meaningful for this requirement.

Regards
Dilip


#18

I agree with what Dilip is suggesting. -1 does have a different meaning within qstat itself that each line belongs to a job instead of an attribute.
With respect to the usage of ‘w’, there is some non-functional code in qstat that sets a value but doesnt use it in any way, so there is no usage error printed…
I have a different suggestion for the option though. How about providing a long format option like --wrap or --no-wrap and having one of them as a default.


#19

The available options in qstat are all simple one letter. IMHO qstat -fw will be the right candidate as -w doesn’t have any defined behavior when used with -f.


#20

mostly, the long options have an associated short option, my suggestion was to have -fw for short and --wrap or --no-wrap as the long option. For that you will have to use getopt_long() instead of getopt().
However, if you are not willing to go that way, ok for me…