This page collects useful information for unix systems and related tools. They are not ordered in any way nor do they cover any specific area, it's simply a collection of things I discovered and wrote down.
How to change recursivly and only apply it to folders? find -type d -print0 | xargs -0 chmod ...
Enter access control lists. An ACL is an ordered list of rules that control file permissions. Each rule specifies three things: an actor, an action, and whether that action is allowed or denied. A rule is also known as an ACE, or access control entry.
To determine whether or not to allow an action, the rules are considered in order. The first rule that is applicable to the current actor and action determines the decision, and no further rules are considered. If none of the rules apply, then the decision is determined by the traditional Unix file permissions.
...
ACLs support "static inheritance." This means that the initial ACL for a newly created file may be determined by the ACLs of one or more of the parent directories. This inheritance happens once, at the time the new file is created. If the ACLs of the parents change in the future, the children won't inherit those changes.
use escape as prefix to simulate meta-keys
a beginning of line
l Clear screen
e Ende
f forward one char (meta-f one word)
b backward one char (meta-b one word)
p previous history entry
n next history entry
r Reverse search history
s search history (forward) (may not work, because ctrl-s is stop)
o Accept current line and fetch next from history
d Type delete character
q type quoted (for inserting control commands)
v "
t Transpose last two chars (meta-t for two words)
k Kill rest of line
u kill beginning of line, save in kill-ring
w kill last word, save to kill-ring
y yank top of kill-ring
x show completion (/ for files, ~ for usernames, $ for variables, @ for hostnames, ! for commands) or create macros ( "(" to start, ")" to end, e to call)
g Abort and ring bell
_ undo
x ctrl-
m-. yank last argument
The folder CVSROOT contains several files which control CVS:
| .# | backups of previous administrative files, created after checkin |
| checkoutlist | contains list of files which are automatically checked out when checked into CVSROOT |
| commitinfo | scripts to be performed before check in |
| config | misc cvs configuration (nothing useful) |
| cvswrappers | defines which files have to be checked in as binary |
| editinfo | obsolete |
| history | holds history of operations, needs to be writeable by everyone, if deleted is not created again |
| loginfo | scripts to be performed after check in (can access log messages) |
| modules | holds list of additional "virtual" modules which alias to other modules or contain them |
| notify | scripts to run for watches and edits |
| rcsinfo | defines the template files for log messages |
| taginfo | scripts to run, when tags are applied |
| updatelog | not part of original CVS distribution, usually holds checkout information from scripts (see below) |
| val-tags | |
| verifymsg | evaluate log messages |
The loginfo file usually contains a commented script which can be used for automatic checkouts
ALL (date; cat; (sleep 2; cd /var/cvs_checkout; umask g+w; cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
This line checks out all modules to /var/cvs_checkout and appends all information written during checkout to updatelog. The umask g+w was added by myself to circumvent group permission problems. If the default umask doesn't include write abilities for group members then other group members can't successfully check out files. The changed umask circumvents this.
This hint is taken from cvsbook.red-bean.com - I wasn't able to reproduce this yet.
Usually the files are checked out with the permissions of the user doing the check out. At least the executable bit can be modified. Simply go to the repository and set the x bit on the ,v -files and when they are checked out the x bit should be set.
If a repository module is shared between several users the problem arises that files created by one user may not be changeable by another because the default group of the first user does not include the second user.
Solution: Set folder g+s (setgid-bit) which "inherits" the group id to subitems when they are created. Every file or directory created has the same group as the parent folder.
-d/--data <data> HTTP POST data (H)
--data-ascii <data> HTTP POST ASCII data (H)
--data-binary <data> HTTP POST binary data (H)
...
-2/--sslv2 Force usage of SSLv2 (H)
-3/--sslv3 Force usage of SSLv3 (H)
-b, --background go to background after startup.
-o, --output-file=FILE log messages to FILE.
-i, --input-file=FILE read URL-s from file.
-nd --no-directories don't create directories.
-x, --force-directories force creation of directories.
-nH, --no-host-directories don't create host directories.
--http-user=USER set http user to USER.
--http-passwd=PASS set http password to PASS.
-U, --user-agent=AGENT identify as AGENT instead of Wget/VERSION.
-r, --recursive recursive web-suck -- use with care!.
-l, --level=NUMBER maximum recursion depth (0 to unlimit).
-k, --convert-links convert non-relative links to relative.
-L, --relative follow relative links only.
-H, --span-hosts go to foreign hosts when recursive.
-np, --no-parent don't ascend to the parent directory.
NEUTRAL="\[\033[0m\]" # Neutral LRED="\[\033[1;31m\]" # Light Red export PS1="$NEUTRAL$LRED\u@\h:\w\$$NEUTRAL "
Option "BlankTime" "10" # 10 minutes
Option "StandbyTime" "0"
Option "SuspendTime" "30"
Option "OffTime" "0"
As far as I now know, there are four utilities that attempt to assist in recovering a lost partition table, or a partition that was deleted by mistake.