Hello.

I would like to have some help writing a script (which should works on FreeBSD where I have sh as default) that should grab a precise string when I do a "ps ax | grep bhyve" command from the terminal. For example :


when I do :



it gives :


when I do :



it gives :



but they are both wrong. The result should be : 0:18

thanks.

They are both correct, because they are giving what the code is asking for.

Awk's filter pattern does not affect the value of fields, and all the commands are asking it to do is print $6 without making any changes to it.

There are various ways to get 0:18 - which one is appropriate depends on how representative the example data is, but a couple of examples...

Strip vm from the start of column 6 with:
Or perhaps better to replace everything not a digit or colon:

(Also, depending on what "vm0:18" actually is, there may be a more direct means to get at that value that doesn't need Awk at all.)

1 members found this post helpful.

both work good. very thanks.

Using the exact fields avoids to match itself in the ps list.
And sub() gives an exit status.

Another option might be to use ps and pgrep for pre-processing.

However, which distro, or OS even, is this for? The behavior of ps depends on which one you have.

Using ps and pgrep together looks overkill for me (including awk)

Just for fun, leaving the awk hammer in the toolbox.

The thread is marked as solved, and unsure the value of all these variations? If efficiency is a goal then one should be going to the source of the information, and since it occurs in the "command" column, that's not likely to be ps?

Checking for what bhyve is, it's a misspelling of "beehive", and the name of virtual machine software running (according to post #1) on FreeBSD.

I can't easily find what the vm0:18 represents, but suspect there's a good chance that whatever it is can be obtained through bhyve/bhyvectl/vmm or similar commands without needing to list then discard information about irrelevant processes (as the ps route does).

Respectfully, without wishing to detract from your initial full and complete answer, for which you have received thanks, I would point out that the initial post is an example of the common task of extracting a substring from a field in a record.
The alternatives demonstrate useful techniques that may be instructive to others. When I started at LQ, I learned a lot from reading such threads.

It was answered by allend, just one more thing to add: we (a few lq members - or at least myself) just play with the issue and find my own way to solve. It is definitely not better and not against the previous answers, just a little bit different. Sometimes this additional solution can help (to OP) to understand, and sometimes we can see different approaches. (there were threads with solutions in more than 5 different languages).
OP will decide anyway...

Please don't mistake my post for whatever that is attempting to address - I would have made (or attempted to make) the same point had post #2 come from someone else, but I guess I didn't word things too well.

I am aware of this - you will find me doing that often enough in the Programming forum - but (hopefully) always with something specific to demonstrate. In this thread I think post #4 is worth highlighting as a useful technique that some Awk users may be unaware of (or need reminding of).

It was when I caught myself about to post a variation of what allend wrote that I realised it was probably not a useful example.

When I wrote "there may be a more direct means to get at that value that doesn't need Awk at all" I was referring to either filtering ps directly (before I realised the relevant text was all in one column), or even better using a different command that outputs the relevant information.

And that's the point I was trying to make: there's likely a better solution via knowing what vm0:18 represents and determine how to get the information from the source.