This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
See this idea on ideas.ibm.com
Command part of "list" category (lsvg, lslv, lssyscfg, lsdev, lsattr, ....) provide the entry point to capture configuration of AIX OS.
Allowing all theses kind of commands to provide "full & easily machine parsable output" using flag (like already do "lsattr -O") will greatly enhance capability to interact with system.
All automated "configuration collection" will be more powerful (shell script, Ansible, ... ) and POWER platform will so be easily deployed, maintained, .... thru automata.
Proposal :
Search for a "not already used" option and reserve it as "generic AIX command standard option" for any new "ls*" command that may be developed later on AIX (same as -v is for version and -h is for help).
Having one generic option that "work everywhere" (ie, avoid one different option per command) will provide more ease of use.
This new option could be "--csv" if easily possible to use "double dash" options within AIX current commands.
Also use "--delim" in order to specify the delimiter to be used (personally I like semi-colon as it is never part of "value" due to its specific shell meaning, but quite sure other people have other preferred delimiter).
Add of the header in first line is mandatory in order to avoid any "foreign data" to be parsed in case of command evolution. A good direction will be to use "#" as first char in order to identify the header line easily and process it as wished. Ie: as part of "one time usage" small shell script, a simple syntax like <my_aix_command --csv | grep -v -e"^#"> will remove the header line (as any comment line within UNIX world). An for more "durable" implementation like Ansible, it will be possible to keep the header line aside and compare the expected header with the one provided by the command, so in case command evolve, there is way to detect new "fields" additions and avoid to integrate "wrong data" because it moved to an other field or was removed because obsolete or wathever reason.
Of course the "formatting output" should combine with existing flags (ie: lsvg does not provide same info than lsvg <vgname> nor lsvg -P <vgname> nor any other used options) as "simply" an "machine readable output formatting".
Going this way (by addition of exhaustive format) will avoid any regression for existing scripts parsing "human readable" aix command output, and will allow aix to move lot more easily to era of automata/Infrastructure As Code/Ansible/...
This will be like a small command change (add of new output format) but giant leap for automation/Infrastructure as a code.
Idea priority | High |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
While I agree with the idea itself - many commands could have output more easily parsable than right now - i disagree strongly with the idea to introduce "--<arg>" as a way to do it. The double-dash is a (non-POSIX) GNU extension to getopts and one doesn't need that in a UNIX system. It sure is possible to find unused command options for every command to access such a functionality. Alternatively there could be an enviroment setting like "export OUTPUTFORMAT=MACHINEREADABLE" to trigger a certain format.
An interesting idea, certainly worthy of consideration.
Please note> one reason the commands have not changed is because these are the layouts that have been available since the late 70's and early 80's. That Linux, e.g., decided to drop many standard commands and replace them with new commands does not break all the programs people have used for years to automatically process these standard ls* commands.
As to two other points: the option -c is frequently used to output results in a single line (noteably in AIX legacy commands such as lslpp, not is classic POSIX commands) and frequently there is an option to omit headers completely.
If this can be done, without breaking compatibility to existing commands - great. Otherwise, I would hesitate to see how many things a change such as this would break for people, as myself, who have worked on and used these programs - asis - for over 25 years.
I definitely agree, some standardization could be good here, specifically, perhaps adding the -F flag to LVM and VPD queries.
_______________________________________________
Device commands do have a standardized way to get this:
_______________________________________________
#################
For lsdev, you can use -F
#################
# lsdev -H -Ccadapter -F 'name;class;subclass;type;location;physloc;description'
name;class;subclass;type;location;physloc;description
ent0;adapter;pciex;df1020e2e304;02-00;U78D2.001.XXXXXXX-P1-C9-T1;PCIe3 4-Port 10GbE SR Adapter (df1020e21410e304)
...
#################
For lsattr, you can do the same
#################
#lsattr -El sys0 -H -F 'attribute:value:description:user_settable'
attribute:value:description:user_settable
SW_dist_intr:false:Enable SW distribution of interrupts:True
autorestart:true:Automatically REBOOT OS after a crash:True
boottype:disk:N/A:False
capacity_inc:0.01:Processor capacity increment:False
capped:false:Partition is capped:False
chown_restrict:true:Chown Restriction Mode:True
clouddev:0:Recreate ODM devices on next boot:True
conslogin:enable:System Console Login :False
cpuguard:enable:CPU Guard:True
_______________________________________________
However, VPD is less standardized.
_______________________________________________
#################
For lssyscfg, I assume you mean lscfg -vl. That command is brutal to parse, and ODM does not have all of this. You can get useful data with:
# lsvpd | while read type data ; do if [[ "${type}" == "*YL" ]] ; then echo "" ; fi ; echo "$type $data" ; done | more | grep -p fcs0
*YL U78D2.001.XXXXXXX-P1-C9-T4
*FC ????????
*DS PCIe3 4-Port 16Gb FC Adapter (df1000e314101406)
*AX fcs0
*PL 03-00
*CD 10140614
*PN 01FT695
*SN Y050HY95A012
*EC P14609
*CC 578E
*MF 001D
*FN 01FT699
*ZM 3
*Z0 0000000C
*Z1 00000001
*Z2 00000000
*Z3 08090000
*Z4 01000001
*Z5 2E343135
*Z6 2E343135
*Z7 C0022C40
*Z8 20000010XXXXXXXX
*Z9 11.4.415.5
*ZA 11.4.415.5
*ZB 00000000
*ZC 00040000
*ZD 000000FF
In this case, it's missing "Network Address", but you can usually convert Z8. This doesn't work on virtual though. I usually do something more like this to get the data I want:
for fcs in `lsdev -C | grep fcs | cut -f 1 -d \ ` ; do
fscsi=`lsdev -p$fcs | grep -i scsi | cut -f 1 -d \ ` ; hn=`hostname`;
echo $hostname `lscfg -vsl $fcs | egrep 'fcs|Address' | tr . \ | tr -s [:space:]` FC ID: `lsattr -a scsi_id -F value -El $fscsi` ; done
vio2a fcs0 U78AE 001 XXXXXXX-P1-C19-L1-T1 Network Address 10000090FXXXXXXX FC ID: 0x450200
vio2a fcs1 U78AE 001 XXXXXXX-P1-C19-L1-T2 Network Address 10000090FXXXXXXX FC ID: 0x460200
That works on virtual hosts also.
_______________________________________________
LVM is the worst, and requires transformation
_______________________________________________
Other than cutting out specific data that you need, the AIX way is to use mkvgdata, and then parse the image.data file it produces.
Alternatively, you can do something like this:
# (lsvg rootvg | cut -c 1-45 ; lsvg rootvg | cut -c 46-999 ) | cut -f 1 -d \( | tr -d \ | tr : \ | while read variable value ; do echo ${variable}=${value} ; done | egrep -v '=$' | sort -r
VOLUMEGROUP=rootvg
VGSTATE=active
VGPERMISSION=read/write
VGIDENTIFIER=00XXXXX00000YYYYY0000ZZZZZZZZZZZ
...
This same works with lslv, or often you can get key info from "lsvg -l rootvg" or similar.
An additional improvement would be to have JSON output (say '--json'), as this would facilitate direct ingestion into multiple platforms.