This is the example from docopt.org:
Naval Fate.
Usage:
naval_fate ship new <name>...
naval_fate ship <name> move <x> <y> [--speed=<kn>]
naval_fate ship shoot <x> <y>
naval_fate mine (set|remove) <x> <y> [--moored|--drifting]
naval_fate -h | --help
naval_fate --version
Options:
-h --help Show this screen.
--version Show version.
--speed=<kn> Speed in knots [default: 10].
--moored Moored (anchored) mine.
--drifting Drifting mine.
I see that options can have a long explanation in the Options: section. For example, it's very clear that naval_fate --version is to Show version.
However, is there a way to provide an extended explanation for commands or positional arguments? For example, how does the user know what naval_fate ship shoot <x> <y> does?
I arrived here with the same question, and I think I've figured out a solution.
The docopt docstring parser isn't very clever or rigorous, which is a good thing, as it means you can put all kinds of other information in your docstring without confusing docopt. For example, there's nothing to stop you adding Commands: or Arguments: sections to your docstring. Here's the docstring for the project I'm currently working on:
"""Helioplot.
Retrieve and plot heliometer results.
Usage:
helioplot fetch <root_dir_path> --host=<host> --password=<password> [--port=<port>] [--database=<database>] [--username=<username>]
Commands:
fetch <root_dir_path> Fetch and dump data into the directory specified
by <root_dir_path>.
Options:
-h --help Show this screen.
--version Show version.
--host=<host> The address of the computer hosting the database
--port=<port> The port number on which the database can be
accessed.
--database=<database> The name of the database.
--username=<username> A database username.
--password=<password> The database password.
"""
Related
I have a problem to add a source file to my QAC configuration. After many tries, I found out that the problem is with too many includes defined as an argument while calling QAC. If I will reduce the number of includes the QAC configuration will pass.
I tried this over the makefile:
#for f in $(filter-out $(QAC_EXCLUDE_FILES),$(QAC_SRC)); do \
echo " - $$f" 1>&2; \
$(QAC) admin -P $(QAC_DIR) -a -- $(QAC_DEF) $(QAC_D_PROJ) $(QAC_INC) $$f >/dev/null; \
done
I also tried to run a single command to add just one file in Command Prompt:
D:/Tools/PRQA_Framework_2.4.0/common/bin/qacli.exe admin -P D:/Output/qac -a -- -Itoo -Imany -Iincludes D:/Src/import.c
I'm pretty sure that the whole command line is not exceeding the limit 8191 characters (it is something about 5500 characters).
I'm using our common company QAC configuration like many of my colleagues without any problem. In the last few days I just add some new includes.
The result is always the same:
Calling from makefile: /usr/bin/sh: -c: line 3: syntax error:
unexpected end of file
Calling from CMD: CreateProcess error=3, the system cannot find
the path specified
But again, if I will just reduce the includes, everything goes nice and smooth.
Also, I would not say it is a problem of CMD because I'm using the same list of includes for my build process without any problem! It is only a problem for QAC.
My setup is Windows 10, MSYS2 tools.
At the and I contact the QAC support and better way how to provide all information to QAC is to generate list file (one line = line source file) with all defines and includes. This way is also much quicker than passing source files one by one.
So the file list qac_sources.txt (generated by makefile) may look like this:
D:/Project/a1.c -D__far_func= -IToo -Imany -Iincludes
D:/Project/a2.c -D__far_func= -IToo -Imany -Iincludes
D:/Project/a3.c -D__far_func= -IToo -Imany -Iincludes
D:/Project/a4.c -D__far_func= -IToo -Imany -Iincludes
And:
D:/Tools/qacli.exe admin -P D:/Project/Output/qac -F D:/Project/Output/qac/qac_sources.txt
Hope this will help somebody.
I know I can get a list of packages included in an image using this command:
bitbake -g <image> && cat pn-buildlist | grep -ve "native" | sort | uniq
Is there a bitbake command to get the description of a specific package? Or perhaps there is a command to get all info on a package, I could simply grep the output of this.
Cheers!
It isn't a bitbake command, but there is oe-pkgdata-util utility (part of openembedded-core). It works in OE build environment (like bitbake). You can query a value from a built package (not recipe) using the read-value subcommand. The basic syntax is:
oe-pkgdata-util read-value <value> <pkg1> [<pkg2>...]
You can query multiple packages, prefix the name of package etc. Just check:
oe-pkgdata-util read-value --help
Here is an example for your question:
tom#pc:~/oe/build> oe-pkgdata-util read-value DESCRIPTION libc6
The GNU C Library is used as the system C library in most systems with the Linux kernel.
BTW, you can query other variables like RDEPENDS, SUMMARY etc.
Please note that if the DESCRIPTION variable is not set in the recipe, it is filled with content of a SUMMARY variable (see doc).
Your question also mentions getting the list of packages in the image. I would say that there are more straightforward ways. For example:
manifest file in the deploy dir (the file is next to the image file): ${DEPLOY_DIR}/images/${MACHINE}/${IMAGE_BASENAME}-${MACHINE}.manifest
file installed-package-names.txt in buildhistory (if you've enabled it). It is inside the folder ${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}/.
FYI, not every package has a description.
I usually read the recipe as it is faster than waiting the bitbake output. Nevertheless, if you wish to read it from bitbake:
bitbake <recipe> -e | grep ^DESCRIPTION=
The description may be written in the recipe, like in here
As a side note, you can get access to each variable with -e, very useful for debugging.
I have several hundred behat tests created by many people who used different tags. I want to clean this up, and to start with I want to list out all the tags which have been used so far.
I wanted to answer my own question as it was something I could not find an answer to elsewhere.
I tried initially to use a custom formatter but that did not work.
https://gist.github.com/paulmozo/fb23d8fb436700381a06
Eventually I crafted a Bash command to suit my purposes
bin/behat --dry-run 2>&1 | tr ' ' '\n' | grep -w #.* | sort -u
This runs the behat command with --dry-run which does not execute the tests, merely outputs the steps so I can pipe them to another tool. The 2>&1 redirects the standard error to null (this is shell dependent). The tr tool breaks every word in the stream into a separate line. The grep searches for lines starting with the # symbol. Finally sort -u sorts the list and returns the uniques.
This command takes about 15 seconds to run and did the job perfectly for me.
I am using following command to get a brief history of the CVS repository.
cvs -d :pserver:*User*:*Password*#*Repo* rlog -N -d "*StartDate* < *EndDate*" *Module*
This works just fine except for one small problem. It lists all tags created on each file in that repository. I want the tag info, but I only want the tags that are created in the date range specified. How do I change this command to do that.
I don't see a way to do that natively with the rlog command. Faced with this problem, I would write a Perl script to parse the output of the command, correlate the tags to the date range that I want and print them.
Another solution would be to parse the ,v files directly, but I haven't found any robust libraries for doing that. I prefer Perl for that type of task, and the parsing modules don't seem to be very high quality.
I want to read a block in zpool storage pool using dd command. Since zpool doesn't create a device file like other volume manager like vxvm. I dunno which block device to use for reading. Is there any way to read block by block data in zpool ?
You can probably use the zdb command. Here is a pdf about it, and the help output.
http://www.bruningsystems.com/osdevcon_draft3.pdf
# zdb --help
zdb: illegal option -- -
Usage: zdb [-CumdibcsDvhL] poolname [object...]
zdb [-div] dataset [object...]
zdb -m [-L] poolname [vdev [metaslab...]]
zdb -R poolname vdev:offset:size[:flags]
zdb -S poolname
zdb -l [-u] device
zdb -C
Dataset name must include at least one separator character '/' or '#'
If dataset name is specified, only that dataset is dumped
If object numbers are specified, only those objects are dumped
Options to control amount of output:
-u uberblock
-d dataset(s)
-i intent logs
-C config (or cachefile if alone)
-h pool history
-b block statistics
-m metaslabs
-c checksum all metadata (twice for all data) blocks
-s report stats on zdb's I/O
-D dedup statistics
-S simulate dedup to measure effect
-v verbose (applies to all others)
-l dump label contents
-L disable leak tracking (do not load spacemaps)
-R read and display block from a device
Below options are intended for use with other options (except -l):
-A ignore assertions (-A), enable panic recovery (-AA) or both (-AAA)
-F attempt automatic rewind within safe range of transaction groups
-U <cachefile_path> -- use alternate cachefile
-X attempt extreme rewind (does not work with dataset)
-e pool is exported/destroyed/has altroot/not in a cachefile
-p <path> -- use one or more with -e to specify path to vdev dir
-P print numbers parsable
-t <txg> -- highest txg to use when searching for uberblocks
Specify an option more than once (e.g. -bb) to make only that option verbose
Default is to dump everything non-verbosely
Unfortunately, I don't know how to use it.
# zdb
tank:
version: 28
name: 'tank'
...
vdev_tree:
...
children[0]:
...
children[0]:
...
path: '/dev/label/bank1d1'
phys_path: '/dev/label/bank1d1'
...
So I took the array indexes 0 0 to get my first disk (bank1d1) and did this command. It did something. I don't know how to read the output.
zdb -R tank 0:0:4e00:200 | strings
Have fun... try not to destroy anything. Here is your warning from the man page:
The zdb command is used by support engineers to diagnose failures and
gather statistics. Since the ZFS file system is always consistent on
disk and is self-repairing, zdb should only be run under the direction
by a support engineer.
And please tell us what you actually were looking for. Was Alan right that you wanted to do backups?
You can read from underlying raw devices in the pool, but as far as I can tell there's no concept of single contiguous block device representing the whole pool.
The pool in ZFS is not a single contiguous block of sectors that 'classic' volume managers are. ZFS internal structure is closer to a tree which would be somewhat challenging to represent as a flat array of blocks.
Ben Rockwood's blog post "zdb: Examining ZFS At Point-Blank Range" may help getting better idea of what's under the hood.
No idea about what might be useful doing so but you certainly can read blocks in the underlying devices used by the pool. They are shown by the zpool status command. If you are really asking about zvols instead of zpools, they are accessible under /dev/zvol/rdsk/pool-name/zvol-name. If you want to look at internal zpool data, you probably want to use zdb.
If you want to backup ZFS filesystems you should be using the following tools:
'zfs snapshot' to create a stable snapshot of the filesystem
'zfs send' to send a copy of the snapshot to somewhere else
'zfs receive' to go back from a snapshot to a filesystem.
'dd' is almost certainly not the tool you should be using. In your case you could 'zfs send' and redirect the output into a file on your other filesystem.
See chapter 7 of the ZFS administration guide for more details.