How to parse the lsblk output and check the values

[bubunia...@gmail.com]

Hi all,

lsblk output something as below. I want to check the that xvdf is mounted at /mnt or not and Size of mount is 20G

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 10G 0 disk
└─xvda1 202:1 0 10G 0 part /
xvdf 202:64 0 20G 0 disk /mnt

I tried to use something

lsblk - f | egrep 'xvdf' | wc -l which returns count=1
lsblk -o SIZE to find out 20G
lsblk to find mount point.

Is there a better way to find all the 3 things using 1 lsblk call or any better way to optimize the OS calls? Any example would be appreciated.

Regards
Pradeep

[marrgol]

lsblk -no MOUNTPOINT,SIZE /dev/xvdf
 
will display a single line with mountpoint and size of xvdf
or return an error if /dev/xvdf does not exist or is not a block device.
 
 
--
mrg

[Bit Twister]

On Sat, 10 Mar 2018 06:35:28 -0800 (PST), bubunia...@gmail.com wrote:
> Hi all,
>
> lsblk output something as below. I want to check the that xvdf is mounted at /mnt or not and Size of mount is 20G
>
>

> Is there a better way to find all the 3 things using 1 lsblk call or
> any better way to optimize the OS calls? Any example would be
> appreciated.

lsblk can output all kinds of information. All you have to do is ask
it to display it. Here, past this in a terminal.

lsblk -l -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,PARTLABEL,UUID | sort -V

In bash scripts, I find using the set command handy for parsing a line.
For example:

set -- $(lsblk -l -o NAME,SIZE,MOUNTPOINT | grep xvdf )
Name=$1
Size=$2
if [ $# -gt 2 ] ; then
MountPoint=$3
else
MountPoint="Not Mounted"
fi

echo "Name = $Name, Size is $Size and Mount point is $MountPoint"

[Grant Taylor]

On 03/10/2018 07:35 AM, bubunia...@gmail.com wrote:
> Is there a better way to find all the 3 things using 1 lsblk call or
> any better way to optimize the OS calls? Any example would be appreciated.

I'd be inclined to pass the output of lsblk (possibly with options
others have listed) into awk and then use awk to extract the information
you are after. Depending on what you need to do with the information,
you may be able to have awk do it for you, or print a line that can set
environment variables that can be used by other things.



--
Grant. . . .
unix || die

[Janis Papanagnou]

On 10.03.2018 19:29, Bit Twister wrote:
> On Sat, 10 Mar 2018 06:35:28 -0800 (PST), bubunia...@gmail.com wrote:
>> Hi all,
>>
>> lsblk output something as below. I want to check the that xvdf is mounted at /mnt or not and Size of mount is 20G
>>
>>
>> Is there a better way to find all the 3 things using 1 lsblk call or
>> any better way to optimize the OS calls? Any example would be
>> appreciated.
>
> lsblk can output all kinds of information. All you have to do is ask
> it to display it. Here, past this in a terminal.
>
> lsblk -l -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,PARTLABEL,UUID | sort -V
>
> In bash scripts, I find using the set command handy for parsing a line.
> For example:
>
> set -- $(lsblk -l -o NAME,SIZE,MOUNTPOINT | grep xvdf )
> Name=$1
> Size=$2

In Ksh, instead of using set and subshell expansion, I find it more
convenient to directly read the variables (see below).

> if [ $# -gt 2 ] ; then
> MountPoint=$3
> else
> MountPoint="Not Mounted"
> fi
>
> echo "Name = $Name, Size is $Size and Mount point is $MountPoint"
>

lsblk -l -o NAME,SIZE,MOUNTPOINT | ... | read -r Name Size Mountpoint
printf "%s\n" "... ${MountPoint:-Not Mounted}"


Janis

[Kenny McCormack]

In article <p82prj$dkh$1...@news-1.m-online.net>,
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
...

>In Ksh, instead of using set and subshell expansion, I find it more
>convenient to directly read the variables (see below).
>

...

>
> lsblk -l -o NAME,SIZE,MOUNTPOINT | ... | read -r Name Size Mountpoint
> printf "%s\n" "... ${MountPoint:-Not Mounted}"

Alas, in bash (and most sh-like shells), the 'read' statement will be
executed in a subshell, and thus the values are only seen in that subshell.
Effectively, the assignments don't get executed at all.

FWIW, while the:

set -- $(...)

method is "portable", I have come to prefer using an array (when
programming in bash):

myArray=($(...))

This has the advantage of not disturbing the passed-in command line args.

P.S. A workaround for the subshell bug is to use a here-document:

read Name Size Mountpoint << EOF
$(lsblk -l -o NAME,SIZE,MOUNTPOINT | ...)
EOF

--
They say compassion is a virtue, but I don't have the time!

- David Byrne -

[Janis Papanagnou]

On 11.03.2018 11:30, Kenny McCormack wrote:
> In article <p82prj$dkh$1...@news-1.m-online.net>,
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> ...
>> In Ksh, instead of using set and subshell expansion, I find it more
>> convenient to directly read the variables (see below).
>>
> ...
>>
>> lsblk -l -o NAME,SIZE,MOUNTPOINT | ... | read -r Name Size Mountpoint
>> printf "%s\n" "... ${MountPoint:-Not Mounted}"
>
> Alas, in bash (and most sh-like shells), the 'read' statement will be
> executed in a subshell, and thus the values are only seen in that subshell.
> Effectively, the assignments don't get executed at all.

The assignment gets executed but is ineffective in those shells, yes; that
subprocess-effect was the reason why I mentioned Ksh explicitly.

>
> FWIW, while the:
>
> set -- $(...)
>
> method is "portable", I have come to prefer using an array (when
> programming in bash):
>
> myArray=($(...))

This is even possible in many of the modern shells. And set destroys
(redefines) the arg-list which may not be desired.

>
> This has the advantage of not disturbing the passed-in command line args.
>
> P.S. A workaround for the subshell bug is to use a here-document:

Given how widespread that subprocess in pipes behaviour is it's arguable
whether that is to be considered a bug. Some shells put all pipeline
processes in subprocesses while it would also be possible that not the
last (as in Ksh) but, say, the first pipeline command would be executed
in the current shell environment; Stephane has made up an example in the
past (but I don't recall the details). Personally I think it has more
value to have the last pipeline command executed in the current shell
process context. The subprocess "bug" behaviour of other shells is one
of many reasons why I prefer Ksh as my standard shell.

>
> read Name Size Mountpoint << EOF
> $(lsblk -l -o NAME,SIZE,MOUNTPOINT | ...)
> EOF

Janis