neulab/tldr huggingface dataset:
sets the mode mask so that subsequently created files have all their write bits cleared. Note that mask operands -r, -w, -x or anything beginning with a <hyphen-minus>, must be preceded by "--" to keep it from being interpreted as an option.
Since umask affects the current shell execution environment, it is generally provided as a shell regular built-in. If it is called in a subshell or separate utility execution environment, such as one of the following:
it does not affect the file mode creation mask of the environment of the caller.
The description of the historical utility was modified to allow it to use the symbolic modes of chmod.  The -s option used in early proposals was changed to -S because -s could be confused with a symbolic_mode form of mask referring to the S_ISUID and S_ISGID bits.
The default output style is unspecified to permit implementors to provide migration to the new symbolic style at the time most appropriate to their users. A -o flag to force octal mode output was omitted because the octal mode may not be sufficient to specify all of the information that may be present in the file mode creation mask when more secure file access permission checks are implemented.
It has been suggested that trusted systems developers might appreciate ameliorating the requirement that the mode mask ``affects'' the file access permissions, since it seems access control lists might replace the mode mask to some degree. The wording has been changed to say that it affects the file permission bits, and it leaves the details of the behavior of how they affect the file access permissions to the description in the System Interfaces volume of POSIX.1‐2017.
Chapter 2, Shell Command Language, chmod
The System Interfaces volume of POSIX.1‐2017, umask()
GIT-RESET(1)                       Git Manual                       GIT-RESET(1)
git-reset - Reset current HEAD to the specified state
git reset [-q] [<tree-ish>] [--] <pathspec>... git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>] git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>...] git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
In the first three forms, copy entries from <tree-ish> to the index. In the last form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <tree-ish>/<commit> defaults to HEAD in all forms.
git reset [-q] [<tree-ish>] [--] <pathspec>..., git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>] These forms reset the index entries for all paths that match the <pathspec> to their state at <tree-ish>. (It does not affect the working tree or the current branch.)
This means that git reset <pathspec> is the opposite of git add <pathspec>. This command is equivalent to git restore [--source=<tree-ish>] --staged <pathspec>....
After running git reset <pathspec> to update the index entry, you can use git-restore(1) to check the contents out of the index to the working tree. Alternatively, using git-restore(1) and specifying a commit with --source, you can copy the contents of a path out of a commit to the index and to the working tree in one go.
git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>...] Interactively select hunks in the difference between the index and <tree-ish> (defaults to HEAD). The chosen hunks are applied in reverse to the index.
This means that git reset -p is the opposite of git add -p, i.e. you can use it to selectively reset hunks. See the “Interactive Mode” section of git-add(1) to learn how to operate the --patch mode.
git reset [<mode>] [<commit>] This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and the working tree depending on <mode>. If <mode> is omitted, defaults to --mixed. The <mode> must be one of the following:
--soft Does not touch the index file or the working tree at all (but resets the head to <commit>, just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.
--mixed Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.
If -N is specified, removed paths are marked as intent-to-add (see git-add(1)).
--hard Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded. Any untracked files or directories in the way of writing any tracked files are simply deleted.
--merge Resets the index and updates the files in the working tree that are different between <commit> and HEAD, but keeps those which are different between the index and working tree (i.e. which have changes which have not been added). If a file that is different between <commit> and the index has unstaged changes, reset is aborted.
In other words, --merge does something like a git read-tree -u -m <commit>, but carries forward unmerged index entries.
--keep Resets index entries and updates files in the working tree that are different between <commit> and HEAD. If a file that is different between <commit> and HEAD has local changes, reset is aborted.
--[no-]recurse-submodules When the working tree is updated, using --recurse-submodules will also recursively reset the working tree of all active submodules according to the commit recorded in the superproject, also setting the submodules' HEAD to be detached at that commit.
-q, --quiet, --no-quiet Be quiet, only report errors. The default behavior is set by the reset.quiet config option.  --quiet and --no-quiet will override the default behavior.
Undo add
$ edit                                     (1) $ git add frotz.c filfre.c $ mailx                                    (2) $ git reset                                (3) $ git pull git://info.example.com/ nitfol  (4)
1. You are happily working on something, and find the changes in these files are in good order. You do not want to see them when you run git diff, because you plan to work on other files and changes with these files are distracting. 2. Somebody asks you to pull, and the changes sound worthy of merging. 3. However, you already dirtied the index (i.e. your index does not match the HEAD commit). But you know the pull you are going to make does not affect frotz.c or filfre.c, so you revert the index changes for these two files. Your changes in working tree remain there. 4. Then you can pull and merge, leaving frotz.c and filfre.c changes still in the working tree.
Undo a commit and redo
$ git commit ... $ git reset --soft HEAD^      (1) $ edit                        (2) $ git commit -a -c ORIG_HEAD  (3)
1. This is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before "reset". 2. Make corrections to working tree files. 3. "reset" copies the old head to .git/ORIG_HEAD; redo the commit by starting with its log message. If you do not need to edit the message further, you can give -C option instead.
See also the --amend option to git-commit(1).
Undo a commit, making it a topic branch
$ git branch topic/wip          (1) $ git reset --hard HEAD~3       (2) $ git switch topic/wip          (3)
1. You have made some commits, but realize they were premature to be in the master branch. You want to continue polishing them in a topic branch, so create topic/wip branch off of the current HEAD. 2. Rewind the master branch to get rid of those three commits. 3. Switch to topic/wip branch and keep working.
Undo commits permanently
$ git commit ... $ git reset --hard HEAD~3   (1)
1. The last three commits (HEAD, HEAD^, and HEAD~2) were bad and you do not want to ever see them again. Do not do this if you have already given these commits to somebody else. (See the "RECOVERING FROM UPSTREAM REBASE" section in git-rebase(1) for the implications of doing so.)
Undo a merge or pull
$ git pull                         (1) Auto-merging nitfol CONFLICT (content): Merge conflict in nitfol Automatic merge failed; fix conflicts and then commit the result. $ git reset --hard                 (2) $ git pull . topic/branch          (3) Updating from 41223... to 13134... Fast-forward $ git reset --hard ORIG_HEAD       (4)
1. Try to update from the upstream resulted in a lot of conflicts; you were not ready to spend a lot of time merging right now, so you decide to do that later. 2. "pull" has not made merge commit, so git reset --hard which is a synonym for git reset --hard HEAD clears the mess from the index file and the working tree. 3. Merge a topic branch into the current branch, which resulted in a fast-forward. 4. But you decided that the topic branch is not ready for public consumption yet. "pull" or "merge" always leaves the original tip of the current branch in ORIG_HEAD, so resetting hard to it brings your index file and the working tree back to that state, and resets the tip of the branch to that commit.
Undo a merge or pull inside a dirty working tree
$ git pull                         (1) Auto-merging nitfol Merge made by recursive. nitfol                |   20 +++++---- ... $ git reset --merge ORIG_HEAD      (2)
1. Even if you may have local modifications in your working tree, you can safely say git pull when you know that the change in the other branch does not overlap with them. 2. After inspecting the result of the merge, you may find that the change in the other branch is unsatisfactory. Running git reset --hard ORIG_HEAD will let you go back to where you were, but it will discard your local changes, which you do not want.  git reset --merge keeps your local changes.
Interrupted workflow Suppose you are interrupted by an urgent fix request while you are in the middle of a large change. The files in your working tree are not in any shape to be committed yet, but you need to get to the other branch for a quick bugfix.
$ git switch feature  ;# you were working in "feature" branch and $ work work work      ;# got interrupted $ git commit -a -m "snapshot WIP"                 (1) $ git switch master $ fix fix fix $ git commit ;# commit with real log $ git switch feature $ git reset --soft HEAD^ ;# go back to WIP state  (2) $ git reset                                       (3)
1. This commit will get blown away so a throw-away log message is OK. 2. This removes the WIP commit from the commit history, and sets your working tree to the state just before you made that snapshot. 3. At this point the index file still has all the WIP changes you committed as snapshot WIP. This updates the index to show your WIP files as uncommitted.
See also git-stash(1).
Reset a single file in the index Suppose you have added a file to your index, but later decide you do not want to add it to your commit. You can remove the file from the index while keeping your changes with git reset.
$ git reset -- frotz.c                      (1) $ git commit -m "Commit files in index"     (2) $ git add frotz.c                           (3)
1. This removes the file from the index while keeping it in the working directory. 2. This commits all other changes in the index. 3. Adds the file to the index again.
Keep changes in working tree while discarding some previous commits Suppose you are working on something and you commit it, and then you continue working a bit more, but now you think that what you have in your working tree should be in another branch that has nothing to do with what you committed previously. You can start a new branch and reset it while keeping the changes in your working tree.
$ git tag start $ git switch -c branch1 $ edit $ git commit ...                            (1) $ edit $ git switch -c branch2                     (2) $ git reset --keep start                    (3)
1. This commits your first edits in branch1. 2. In the ideal world, you could have realized that the earlier commit did not belong to the new topic when you created and switched to branch2 (i.e.  git switch -c branch2 start), but nobody is perfect. 3. But you can use reset --keep to remove the unwanted commit after you switched to branch2.
Split a commit apart into a sequence of commits Suppose that you have created lots of logically separate changes and committed them together. Then, later you decide that it might be better to have each logical chunk associated with its own commit. You can use git reset to rewind history without changing the contents of your local files, and then successively use git add -p to interactively select which hunks to include into each commit, using git commit -c to pre-populate the commit message.
$ git reset -N HEAD^                        (1) $ git add -p                                (2) $ git diff --cached                         (3) $ git commit -c HEAD@{1}                    (4) ...                                         (5) $ git add ...                               (6) $ git diff --cached                         (7) $ git commit ...                            (8)
1. First, reset the history back one commit so that we remove the original commit, but leave the working tree with all the changes. The -N ensures that any new files added with HEAD are still marked so that git add -p will find them. 2. Next, we interactively select diff hunks to add using the git add -p facility. This will ask you about each diff hunk in sequence and you can use simple commands such as "yes, include this", "No don’t include this" or even the very powerful "edit" facility. 3. Once satisfied with the hunks you want to include, you should verify what has been prepared for the first commit by using git diff --cached. This shows all the changes that have been moved into the index and are about to be committed. 4. Next, commit the changes stored in the index. The -c option specifies to pre-populate the commit message from the original message that you started with in the first commit. This is helpful to avoid retyping it. The HEAD@{1} is a special notation for the commit that HEAD used to be at prior to the original reset commit (1 change ago). See git-reflog(1) for more details. You may also use any other valid commit reference. 5. You can repeat steps 2-4 multiple times to break the original code into any number of commits. 6. Now you’ve split out many of the changes into their own commits, and might no longer use the patch mode of git add, in order to select all remaining uncommitted changes. 7. Once again, check to verify that you’ve included what you want to. You may also wish to verify that git diff doesn’t show any remaining changes to be committed later. 8. And finally create the final commit.
The tables below show what happens when running:
git reset --option target
to reset the HEAD to another commit (target) with the different reset options depending on the state of the files.
In these tables, A, B, C and D are some different states of a file. For example, the first line of the first table means that if a file is in state A in the working tree, in state B in the index, in state C in HEAD and in state D in the target, then git reset --soft target will leave the file in the working tree in state A and in the index in state B. It resets (i.e. moves) the HEAD (i.e. the tip of the current branch, if you are on one) to target (which has the file in state D).
working index HEAD target         working index HEAD ---------------------------------------------------- A       B     C    D     --soft   A       B     D --mixed  A       D     D --hard   D       D     D --merge (disallowed) --keep  (disallowed)
working index HEAD target         working index HEAD ---------------------------------------------------- A       B     C    C     --soft   A       B     C --mixed  A       C     C --hard   C       C     C --merge (disallowed) --keep   A       C     C
working index HEAD target         working index HEAD ---------------------------------------------------- B       B     C    D     --soft   B       B     D --mixed  B       D     D --hard   D       D     D --merge  D       D     D --keep  (disallowed)
working index HEAD target         working index HEAD ---------------------------------------------------- B       B     C    C     --soft   B       B     C --mixed  B       C     C --hard   C       C     C --merge  C       C     C --keep   B       C     C
working index HEAD target         working index HEAD ---------------------------------------------------- B       C     C    D     --soft   B       C     D --mixed  B       D     D --hard   D       D     D --merge (disallowed) --keep  (disallowed)
working index HEAD target         working index HEAD ---------------------------------------------------- B       C     C    C     --soft   B       C     C --mixed  B       C     C --hard   C       C     C --merge  B       C     C --keep   B       C     C
reset --merge is meant to be used when resetting out of a conflicted merge. Any mergy operation guarantees that the working tree file that is involved in the merge does not have a local change with respect to the index before it starts, and that it writes the result out to the working tree. So if we see some difference between the index and the target and also between the index and the working tree, then it means that we are not resetting out from a state that a mergy operation left after failing with a conflict. That is why we disallow --merge option in this case.
reset --keep is meant to be used when removing some of the last commits in the current branch while keeping changes in the working tree. If there could be conflicts between the changes in the commit we want to remove and the changes in the working tree we want to keep, the reset is disallowed. That’s why it is disallowed if there are both changes between the working tree and HEAD, and between HEAD and the target. To be safe, it is also disallowed when there are unmerged entries.
The following tables show what happens when there are unmerged entries:
working index HEAD target         working index HEAD ---------------------------------------------------- X       U     A    B     --soft  (disallowed) --mixed  X       B     B --hard   B       B     B --merge  B       B     B --keep  (disallowed)
working index HEAD target         working index HEAD ---------------------------------------------------- X       U     A    A     --soft  (disallowed) --mixed  X       A     A --hard   A       A     A --merge  A       A     A --keep  (disallowed)
X means any state and U means an unmerged index.
UTMPDUMP(1)                       User Commands                      UTMPDUMP(1)
utmpdump - dump UTMP and WTMP files in raw format
utmpdump [options] filename
utmpdump is a simple program to dump UTMP and WTMP files in raw format, so they can be examined. utmpdump reads from stdin unless a filename is passed.
-f, --follow Output appended data as the file grows.
-o, --output file Write command output to file instead of standard output.
-r, --reverse Undump, write back edited login information into the utmp or wtmp files.
utmpdump can be useful in cases of corrupted utmp or wtmp entries. It can dump out utmp/wtmp to an ASCII file, which can then be edited to remove bogus entries, and reintegrated using:
utmpdump -r < ascii_file > wtmp
But be warned, utmpdump was written for debugging purposes only.
File formats Only the binary version of the utmp(5) is standardised. Textual dumps may become incompatible in future.
The version 2.28 was the last one that printed text output using ctime(3) timestamp format. Newer dumps use millisecond precision ISO-8601 timestamp format in UTC-0 timezone. Conversion from former timestamp format can be made to binary, although attempt to do so can lead the timestamps to drift amount of timezone offset.
You may not use the -r option, as the format for the utmp/wtmp files strongly depends on the input format. This tool was not written for normal use, but for debugging only.
Michael Krapp
last(1), w(1), who(1), utmp(5)
The utmpdump command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
BRCTL(8)                                                                BRCTL(8)
brctl - ethernet bridge administration
brctl [command]
brctl is used to set up, maintain, and inspect the ethernet bridge configuration in the Linux kernel.
An ethernet bridge is a device commonly used to connect different networks of ethernets together, so that these ethernets will appear as one ethernet to the participants.
Each of the ethernets being connected corresponds to one physical interface in the bridge. These individual ethernets are bundled into one bigger ('logical') ethernet, this bigger ethernet corresponds to the bridge network interface.
The command brctl addbr <name> creates a new instance of the ethernet bridge. The network interface corresponding to the bridge will be called <name>.
The command brctl delbr <name> deletes the instance <name> of the ethernet bridge. The network interface corresponding to the bridge must be down before it can be deleted!
The command brctl show shows all current instances of the ethernet bridge.
Each bridge has a number of ports attached to it. Network traffic coming in on any of these ports will be forwarded to the other ports transparently, so that the bridge is invisible to the rest of the network (i.e. it will not show up in traceroute(8) ).
The command brctl addif <brname> <ifname> will make the interface <ifname> a port of the bridge <brname>. This means that all frames received on <ifname> will be processed as if destined for the bridge. Also, when sending frames on <brname>, <ifname> will be considered as a potential output interface.
The command brctl delif <brname> <ifname> will detach the interface <ifname> from the bridge <brname>.
The command brctl show <brname> will show some information on the bridge and its attached ports.
The bridge keeps track of ethernet addresses seen on each port. When it needs to forward a frame, and it happens to know on which port the destination ethernet address (specified in the frame) is located, it can 'cheat' by forwarding the frame to that port only, thus saving a lot of redundant copies and transmits.
However, the ethernet address location data is not static data. Machines can move to other ports, network cards can be replaced (which changes the machine's ethernet address), etc.
brctl showmacs <brname> shows a list of learned MAC addresses for this bridge.
brctl setageing <brname> <time> sets the ethernet (MAC) address ageing time, in seconds. After <time> seconds of not having seen a frame coming from a certain address, the bridge will time out (delete) that address from the Forwarding DataBase (fdb).
brctl setgcint <brname> <time> sets the garbage collection interval for the bridge <brname> to <time> seconds. This means that the bridge will check the forwarding database for timed out entries every <time> seconds.
Multiple ethernet bridges can work together to create even larger networks of ethernets using the IEEE 802.1d spanning tree protocol. This protocol is used for finding the shortest path between two ethernets, and for eliminating loops from the topology. As this protocol is a standard, Linux bridges will interwork properly with other third party bridge products. Bridges communicate with each other by sending and receiving BPDUs (Bridge Protocol Data Units). These BPDUs can be recognized by an ethernet destination address of 01:80:c2:00:00:00.
The spanning tree protocol can also be turned off (for those situations where it just doesn't make sense, for example when this Linux box is the only bridge on the LAN, or when you know that there are no loops in the topology.)
brctl(8) can be used for configuring certain spanning tree protocol parameters. For an explanation of these parameters, see the IEEE 802.1d specification (or send me an email). The default values should be just fine. If you don't know what these parameters mean, you probably won't feel the desire to tweak them.
brctl stp <bridge> <state> controls this bridge instance's participation in the spanning tree protocol. If <state> is "on" or "yes" the STP will be turned on, otherwise it will be turned off.  When turned off, the bridge will not send or receive BPDUs, and will thus not participate in the spanning tree protocol. If your bridge isn't the only bridge on the LAN, or if there are loops in the LAN's topology, DO NOT turn this option off. If you turn this option off, please know what you are doing.
brctl setbridgeprio <bridge> <priority> sets the bridge's priority to <priority>. The priority value is an unsigned 16-bit quantity (a number between 0 and 65535), and has no dimension. Lower priority values are 'better'. The bridge with the lowest priority will be elected 'root bridge'.
brctl setfd <bridge> <time> sets the bridge's 'bridge forward delay' to <time> seconds.
brctl sethello <bridge> <time> sets the bridge's 'bridge hello time' to <time> seconds.
brctl setmaxage <bridge> <time> sets the bridge's 'maximum message age' to <time> seconds.
brctl setpathcost <bridge> <port> <cost> sets the port cost of the port <port> to <cost>. This is a dimensionless metric.
brctl setportprio <bridge> <port> <priority> sets the port <port>'s priority to <priority>. The priority value is an unsigned 8-bit quantity (a number between 0 and 255), and has no dimension. This metric is used in the designated port and root port selection algorithms.
brctl(8) is obsolete. Some features such as STP guard, hairpin mode, fast leave and root block are intentionally not implemented in this command. Instead use bridge command from iproute2 package for a more full set of features.
iptables(8)
Lennert Buytenhek <buytenh@gnu.org> Stephen Hemminger <stephen@networkplumber.org>
RPMBUILD(8)                                                          RPMBUILD(8)
rpmbuild - Build RPM Package(s)
BUILDING PACKAGES: rpmbuild {-ba|-bb|-bp|-bc|-bi|-bl|-bs|-br} [rpmbuild-options] SPECFILE ...
rpmbuild {-ra|-rb|-rp|-rc|-ri|-rl|-rs|-rr} [rpmbuild-options] SOURCEPACKAGE ...
rpmbuild {-ta|-tb|-tp|-tc|-ti|-tl|-ts|-tr} [rpmbuild-options] TARBALL ...
rpmbuild {--rebuild|--recompile} SOURCEPKG ...
MISCELLANEOUS: rpmbuild --showrc
rpmbuild-options [--buildroot DIRECTORY] [--clean] [--nobuild] [--rmsource] [--rmspec] [--short-circuit] [--build-in-place] [--noprep] [--noclean] [--nocheck] [--rpmfcdebug] [--target PLATFORM] [--with OPTION] [--without OPTION]
rpmbuild is used to build both binary and source software packages.  A package consists of an archive of files and meta-data used to install and erase the archive files.  The meta-data includes helper scripts, file attributes, and descriptive information about the package.  Packages come in two varieties: binary packages, used to encapsulate software to be installed, and source packages, containing the source code and recipe necessary to produce binary packages.
One of the following basic modes must be selected: Build Package, Build Package from Tarball, Recompile Package, Show Configuration.
GENERAL OPTIONS These options can be used in all the different modes.
-?, --help Print a longer usage message then normal.
--version Print a single line containing the version number of rpm being used.
--quiet Print as little as possible - normally only error messages will be displayed.
-v     Print verbose information - normally routine progress messages will be displayed.
-vv    Print lots of ugly debugging information.
--rpmfcdebug Enables to debug dependencies generation.
--rcfile FILELIST Each of the files in the colon separated FILELIST is read sequentially by rpm for configuration information.  Only the first file in the list must exist, and tildes will be expanded to the value of $HOME.  The default FILELIST is /usr/lib/rpm/rpmrc:/usr/lib/rpm/<vendor>/rpmrc:/etc/rpmrc:~/.rpmrc.
--pipe CMD Pipes the output of rpm to the command CMD.
--dbpath DIRECTORY Use the database in DIRECTORY rather than the default path /var/lib/rpm
--root DIRECTORY Use the file system tree rooted at DIRECTORY for all operations. Note that this means the database within DIRECTORY will be used for dependency checks and any scriptlet(s) (e.g. %post if installing, or %prep if building, a package) will be run after a chroot(2) to DIRECTORY.
-D, --define='MACRO EXPR' Defines MACRO with value EXPR.
--scm=SCM Select the SCM to use with %autosetup, if one is not set in the spec file.  Note that not all values for SCM, e.g., patch (the default) and gendiff, git, or quilt work interchangeably with all other patches and options stated in the %autosetup line, especially option -pN.
BUILD OPTIONS The general form of an rpm build command is
rpmbuild {-bSTAGE|-rSTAGE|-tSTAGE} [rpmbuild-options] FILE ...
The argument used is -b if a spec file is being used to build the package, -r if a source package is to be rebuilt and -t if rpmbuild should look inside of a (possibly compressed) tar file for the spec file to use.
Packages are built in a number of stages.  The first six correspond to the following sections in a spec file: %prep, %generate_buildrequires, %build, %install, %check and %clean.  Finally, binary and source packages are created in an assembly stage.
The STAGE character specifies the stage to finish with (after doing all the stages preceding it), and is one of:
-ba    Perform a full build - executes up to and including the assembly stage.  In most cases, this is the option to choose.
-bb    Build just the binary packages - executes up to and including the assembly stage, but without creating the source package.
-bp    Unpack the sources and apply any patches - executes the %prep stage only.
-bc    Compile the sources - executes up to and including the %build stage.  This generally involves the equivalent of a "make".
-bi    Install the binaries into the build root - executes up to and including the %check stage.  This generally involves the equivalent of a "make install" and "make check".
-bl    Do a "list check" - the %files section from the spec file is macro expanded, and checks are made to verify that each file exists.
-bs    Build just the source package - skips straight to the assembly stage, without executing any of the preceding stages or creating binary packages.
-br    Build just the source package, but also parse and include dynamic build dependencies - executes up to and including the %generate_buildrequires stage and then skips straight to the assembly stage, without creating binary packages.  This command can be used to fully resolve dynamic build dependencies.  See the DYNAMIC BUILD DEPENDENCIES section for details.
The following options may also be used:
--buildroot DIRECTORY When building a package, override the BuildRoot tag with directory DIRECTORY.
--clean Remove the build tree after the packages are made.
--nobuild Do not execute any build stages.  Useful for testing out spec files.
--noprep Do not execute %prep build stage even if present in spec.
--noclean Do not execute %clean build stage even if present in spec.
--nocheck Do not execute %check build stage even if present in spec.
--nodebuginfo Do not generate debuginfo packages.
--nodeps Do not verify build dependencies.
--rmsource Remove the sources after the build (may also be used standalone, e.g. "rpmbuild --rmsource foo.spec").
--rmspec Remove the spec file after the build (may also be used standalone, eg.  "rpmbuild --rmspec foo.spec").
--short-circuit Skip straight to specified stage (i.e., skip all stages leading up to the specified stage).  Only valid with -bc, -bi, and -bb. Useful for local testing only.  Packages built this way will be marked with an unsatisfiable dependency to prevent their accidental use.
--build-in-place Build from locally checked out sources.  Sets _builddir to current working directory.  Skips handling of -n and untar in the %setup and the deletion of the buildSubdir.
--target PLATFORM When building the package, interpret PLATFORM as arch-vendor-os and set the macros %_target, %_target_cpu, and %_target_os accordingly.
--with OPTION Enable configure OPTION for build.
--without OPTION Disable configure OPTION for build.
REBUILD AND RECOMPILE OPTIONS There are two other ways to invoke building with rpm:
rpmbuild --rebuild|--recompile SOURCEPKG ...
When invoked this way, rpmbuild installs the named source package, and does a prep, compile and install.  In addition, --rebuild builds a new binary package.  When the build has completed, the build directory is removed (as in --clean) and the the sources and spec file for the package are removed.
These options are now superseded by the -r* options which allow much more fine control over what stages of the build to run.
DYNAMIC BUILD DEPENDENCIES When the %generate_buildrequires stage runs and some of the newly generated BuildRequires are not satisfied, rpmbuild creates an intermediate source package ending in buildreqs.nosrc.rpm, which has the new BuildRequires, and exits with code 11.  This package can then be used in place of the original source package to resolve and install the missing build dependencies in the usual way, such as with dnf- builddep(8).
Multiple layers of dynamic build dependencies may exist in a spec file; the presence of specific BuildRequires on the system may yield new BuildRequires next time a build is performed with the same source package.  The easiest way to ensure that all dynamic build dependencies are satisfied is to run the -br command, install the new dependencies of the buildreqs.nosrc.rpm package and repeat the whole procedure until rpmbuild no longer exits with code 11.
If the -br command is coupled with --nodeps, exit code 11 is always returned and a buildreqs.nosrc.rpm package is always created.
SHOWRC The command
rpmbuild --showrc
shows the values rpmbuild will use for all of the options are currently set in rpmrc and macros configuration file(s).
rpmrc Configuration /usr/lib/rpm/rpmrc /usr/lib/rpm/<vendor>/rpmrc /etc/rpmrc ~/.rpmrc
Macro Configuration /usr/lib/rpm/macros /usr/lib/rpm/<vendor>/macros /etc/rpm/macros ~/.rpmmacros
Temporary /var/tmp/rpm*
gendiff(1), popt(3), rpm(8), rpm2cpio(8), rpmkeys(8) rpmspec(8), rpmsign(8),
rpmbuild --help - as rpm supports customizing the options via popt aliases it's impossible to guarantee that what's described in the manual matches what's available.
Marc Ewing <marc@redhat.com> Jeff Johnson <jbj@redhat.com> Erik Troan <ewt@redhat.com>
javac(1)                     General Commands Manual                    javac(1)
Name javac - Java programming language compiler
javac [ options ] [ sourcefiles ] [ classes ] [ @argfiles ]
Arguments may be in any order.
sourcefiles One or more source files to be compiled (such as MyClass.java).
classes One or more classes to be processed for annotations (such as MyPackage.MyClass).
@argfiles One or more files that lists options and source files. The -J options are not allowed in these files.
The javac tool reads class and interface definitions, written in the Java programming language, and compiles them into bytecode class files. It can also process annotations in Java source files and classes.
There are two ways to pass source code file names to javac:
o For a small number of source files, simply list the file names on the command line.
o For a large number of source files, list the file names in a file, separated by blanks or line breaks. Then use the list file name on the javac command line, preceded by an @ character.
Source code file names must have .java suffixes, class file names must have .class suffixes, and both source and class files must have root names that identify the class. For example, a class called MyClass would be written in a source file called MyClass.java and compiled into a bytecode class file called MyClass.class.
Inner class definitions produce additional class files. These class files have names combining the inner and outer class names, such as MyClass$MyInnerClass.class.
You should arrange source files in a directory tree that reflects their package tree. For example, if you keep all your source files in /workspace, the source code for com.mysoft.mypack.MyClass should be in /workspace/com/mysoft/mypack/MyClass.java.
By default, the compiler puts each class file in the same directory as its source file. You can specify a separate destination directory with -d (see Options, below).
The compiler has a set of standard options that are supported on the current development environment and will be supported in future releases. An additional set of non-standard options are specific to the current virtual machine and compiler implementations and are subject to change in the future. Non-standard options begin with -X.
Standard Options -Akey[=value] Options to pass to annotation processors. These are not interpreted by javac directly, but are made available for use by individual processors. key should be one or more identifiers separated by ".".
-cp path or -classpath path Specify where to find user class files, and (optionally) annotation processors and source files. This class path overrides the user class path in the CLASSPATH environment variable. If neither CLASSPATH, -cp nor -classpath is specified, the user class path consists of the current directory. See Setting the Class Path for more details. >If the -sourcepath option is not specified, the user class path is also searched for source files. If the -processorpath option is not specified, the class path is also searched for annotation processors.
-Djava.ext.dirs=directories Override the location of installed extensions.
-Djava.endorsed.dirs=directories Override the location of endorsed standards path.
-d directory Set the destination directory for class files. The directory must already exist; javac will not create it. If a class is part of a package, javac puts the class file in a subdirectory reflecting the package name, creating directories as needed. For example, if you specify -d /home/myclasses and the class is called com.mypackage.MyClass, then the class file is called /home/myclasses/com/mypackage/MyClass.class. If -d is not specified, javac puts each class files in the same directory as the source file from which it was generated. Note: The directory specified by -d is not automatically added to your user class path.
-deprecation Show a description of each use or override of a deprecated member or class. Without -deprecation, javac shows a summary of the source files that use or override deprecated members or classes. -deprecation is shorthand for -Xlint:deprecation.
-encoding encoding Set the source file encoding name, such as EUC-JP and UTF-8. If -encoding is not specified, the platform default converter is used.
-endorseddirs directories Override the location of endorsed standards path.
-extdirs directories Overrides the location of the ext directory. The directories variable is a colon-separated list of directories. Each JAR archive in the specified directories is searched for class files. All JAR archives found are automatically part of the class path. If you are cross-compiling (compiling classes against bootstrap and extension classes of a different Java platform implementation), this option specifies the directories that contain the extension classes. See Cross-Compilation Options for more information.
-g Generate all debugging information, including local variables. By default, only line number and source file information is generated.
-g:none Do not generate any debugging information.
-g:{keyword list} Generate only some kinds of debugging information, specified by a comma separated list of keywords. Valid keywords are:
source Source file debugging information
lines Line number debugging information
vars Local variable debugging information
-help Print a synopsis of standard options.
-implicit:{class,none} Controls the generation of class files for implicitly loaded source files. To automatically generate class files, use -implicit:class. To suppress class file generation, use -implicit:none. If this option is not specified, the default is to automatically generate class files. In this case, the compiler will issue a warning if any such class files are generated when also doing annotation processing. The warning will not be issued if this option is set explicitly. See Searching For Types.
-Joption Pass option to the java launcher called by javac. For example, -J-Xms48m sets the startup memory to 48 megabytes. It is a common convention for -J to pass options to the underlying VM executing applications written in Java. Note: CLASSPATH, -classpath, -bootclasspath, and -extdirs do not specify the classes used to run javac. Fiddling with the implementation of the compiler in this way is usually pointless and always risky. If you do need to do this, use the -J option to pass through options to the underlying java launcher.
-nowarn Disable warning messages. This has the same meaning as -Xlint:none.
-proc: {none,only} Controls whether annotation processing and/or compilation is done. -proc:none means that compilation takes place without annotation processing. -proc:only means that only annotation processing is done, without any subsequent compilation.
-processor class1[,class2,class3...] Names of the annotation processors to run. This bypasses the default discovery process.
-processorpath path Specify where to find annotation processors; if this option is not used, the class path will be searched for processors.
-s dir Specify the directory where to place generated source files. The directory must already exist; javac will not create it. If a class is part of a package, the compiler puts the source file in a subdirectory reflecting the package name, creating directories as needed. For example, if you specify -s /home/mysrc and the class is called com.mypackage.MyClass, then the source file will be placed in /home/mysrc/com/mypackage/MyClass.java.
-source release Specifies the version of source code accepted. The following values for release are allowed:
1.3 The compiler does not support assertions, generics, or other language features introduced after Java SE 1.3.
1.4 The compiler accepts code containing assertions, which were introduced in Java SE 1.4.
1.5 The compiler accepts code containing generics and other language features introduced in Java SE 5.
5  Synonym for 1.5.
1.6 No language changes were introduced in Java SE 6. However, encoding errors in source files are now reported as errors instead of warnings as in previous releases of Java SE.
6  Synonym for 1.6.
1.7 This is the default value. The compiler accepts code with features introduced in Java SE 7.
7  Synonym for 1.7.
-sourcepath sourcepath Specify the source code path to search for class or interface definitions. As with the user class path, source path entries are separated by colons (:) and can be directories, JAR archives, or ZIP archives. If packages are used, the local path name within the directory or archive must reflect the package name. Note: Classes found through the class path may be subject to automatic recompilation if their sources are also found. See Searching For Types.
-verbose Verbose output. This includes information about each class loaded and each source file compiled.
-version Print version information.
-Werror Terminate compilation if warnings occur.
-X Display information about non-standard options and exit.
Cross-Compilation Options By default, classes are compiled against the bootstrap and extension classes of the platform that javac shipped with. But javac also supports cross-compiling, where classes are compiled against a bootstrap and extension classes of a different Java platform implementation. It is important to use -bootclasspath and -extdirs when cross-compiling; see Cross-Compilation Example below.
-target version Generate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also 6), and 1.7 (also 7).
The default for -target depends on the value of -source:
o If -source is not specified, the value of -target is 1.7
o If -source is 1.2, the value of -target is 1.4
o If -source is 1.3, the value of -target is 1.4
o If -source is 1.5, the value of -target is 1.7
o If -source is 1.6, the value of -target is 1.7
o For all other values of -source, the value of -target is the value of -source.
-bootclasspath bootclasspath Cross-compile against the specified set of boot classes. As with the user class path, boot class path entries are separated by colons (:) and can be directories, JAR archives, or ZIP archives.
Non-Standard Options -Xbootclasspath/p:path Prepend to the bootstrap class path.
-Xbootclasspath/a:path Append to the bootstrap class path.
-Xbootclasspath/:path Override location of bootstrap class files.
-Xlint Enable all recommended warnings. In this release, enabling all available warnings is recommended.
-Xlint:all Enable all recommended warnings. In this release, enabling all available warnings is recommended.
-Xlint:none Disable all warnings.
-Xlint:name Enable warning name. See the section Warnings That Can Be Enabled or Disabled with -Xlint Option for a list of warnings you can enable with this option.
-Xlint:-name Disable warning name. See the section Warnings That Can Be Enabled or Disabled with -Xlint Option for a list of warnings you can disable with this option.
-Xmaxerrs number Set the maximum number of errors to print.
-Xmaxwarns number Set the maximum number of warnings to print.
-Xstdout filename Send compiler messages to the named file. By default, compiler messages go to System.err.
-Xprefer:{newer,source} Specify which file to read when both a source file and class file are found for a type. (See Searching For Types). If -Xprefer:newer is used, it reads the newer of the source or class file for a type (default). If the -Xprefer:source option is used, it reads source file. Use -Xprefer:source when you want to be sure that any annotation processors can access annotations declared with a retention policy of SOURCE.
-Xpkginfo:{always,legacy,nonempty} Specify handling of package-info files
-Xprint Print out textual representation of specified types for debugging purposes; perform neither annotation processing nor compilation. The format of the output may change.
-XprintProcessorInfo Print information about which annotations a processor is asked to process.
-XprintRounds Print information about initial and subsequent annotation processing rounds.
Warnings That Can Be Enabled or Disabled with -Xlint Option Enable warning name with the option -Xlint:name, where name is one of the following warning names. Similarly, you can disable warning name with the option -Xlint:-name:
cast Warn about unnecessary and redundant casts. For example: String s = (String)"Hello!"
classfile Warn about issues related to classfile contents.
deprecation Warn about use of deprecated items. For example: java.util.Date myDate = new java.util.Date(); int currentDay = myDate.getDay(); The method java.util.Date.getDay has been deprecated since JDK 1.1.
dep-ann Warn about items that are documented with an @deprecated Javadoc comment, but do not have a @Deprecated annotation. For example: /** * @deprecated As of Java SE 7, replaced by {@link #newMethod()} */
public static void deprecatedMethood() { }
public static void newMethod() { }
divzero Warn about division by constant integer 0. For example: int divideByZero = 42 / 0;
empty Warn about empty statements after if statements. For example: class E { void m() { if (true) ; } }
fallthrough Check switch blocks for fall-through cases and provide a warning message for any that are found. Fall-through cases are cases in a switch block, other than the last case in the block, whose code does not include a break statement, allowing code execution to "fall through" from that case to the next case. For example, the code following the case 1 label in this switch block does not end with a break statement: switch (x) { case 1: System.out.println("1"); //  No break statement here. case 2: System.out.println("2"); } If the -Xlint:fallthrough flag were used when compiling this code, the compiler would emit a warning about "possible fall-through into case," along with the line number of the case in question.