Homepage: https://github.com/dlewan/cpio-mode
Author: Douglas Lewan
Updated:
Handle cpio archives in the style of dired
This package implements cpio-mode,
a mode for working with cpio archives
through a dired-like interface.
Documentation:
NAME: cpio-mode
USAGE:
(load-library 'cpio-mode) OR
(require 'cpio-mode)
Once loaded, there are several ways to invoke cpio-mode:
• M-x cpio-mode
• If you want to put a cpio-archive into cpio-mode autmatically,
then add the following to your .emacs:
(add-hook 'find-file-hook 'cpio-mode-find-file-hook)
• Another way to do this would be to modify magic-mode-alist
(setq magic-mode-alist
(add-to-list 'magic-mode-alist
(cons 'cpio-discern-archive-type 'cpio-mode))).
• If you only care about archives that end .cpio,
then the following would also work:
(setq auto-mode-alist
(add-to-list 'auto-mode-alist (cons "\\.cpio\\'" 'cpio-mode))).
DESCRIPTION:
cpio-mode presents a cpio archive as if it were a directory
in a manner like dired-mode.
tar-mode already does such a thing for tar archives,
and some ideas (and likely code) have been adapted from tar-mode.
To automatically invoke cpio-mode when finding a file
add the following to your find-file-hook.
You can use toggle-cpio-mode to switch between cpio-mode
and fundamental mode.
KEYMAP:
This should be conceptually as close to dired as I can make it.
OPTIONS:
ENVIRONMENT:
Early development was done under emacs 24.2
on the Fedora 18 distribution of 64 bit GNU/Linux.
Later development happened under emacs 24.5
on GNU/Linux Mint, Linux kernel 4.4.0.
Current development is happening on emacs 24.5
on GNU/Linux Trisquel, Linux Kernel 4.4.0.
RETURN CODE:
NOTES:
Binary formats are not yet implemented.
CAVEATS:
Only regular files can be edited.
I'm not sure what to do with symbolic links yet.
SECURITY ISSUES:
There are no ownership/group-ship tests on anything.
You could create an archive with bad behavior
(for example, a set-uid executable)
when unpacked by root.
cpio-mode.el is the entry point to all of cpio-mode code.
It defines the archive management variables and functions
that define cpio-mode.
That said, there are other components.
1. There's some generically useful code
defined in
• cpio-generic.el, truly generic code,
• cpio-modes.el, file-mode related information,
2. Every archive format has its own file:
cpio-bin for the cpio binary format,
cpio-crc for the cpio CRC format,
etc.
3. cpio-mode.el, this file, defining the cpio logic
reflected in the catalog,
a list of the information of all the headers
in the current archive.
4. The package cpio-dired, defining the user interface.
The following figure shows the relationships
among those components.
+----------------------+ +-------------+ +-------------+
| Format specific code | | | | |
| +---------------+ | | | | |
| | cpio-bin | | | | | |
| | +--------------+ | | CPIO | | dired-like |
| +-|cpio-crc | |<->| Logic |<->| UI |
| | +-------------+ | | | | |
| +-| hpbin | | | | | |
| | +------------+ | | | | |
| +-| ··· | | | | | |
| +------------+ | | | | |
+----------------------+ +-------------+ +-------------+
Λ Λ Λ
| | |
V V V
+----------------------------------------------------------+
| generic code |
| +------------+ +--------------+ +-----+ |
| | cpio-modes | | cpio-generic | | ··· | |
| +------------+ +--------------+ +-----+ |
+----------------------------------------------------------+
The basic idea is that the format-spedific code parses and makes headers
while all the cpio logic uses those parsed headers to edit
and calls format-specific parsing and making functions.
The main data structures are the following.
0. Parsed headers, an inode-like array structure.
1. Entries, an array containing a parsed header,
the header start and the contents start.
2. The catalog, a list of the entries in the cpio archive,
including the trailer.
3. The buffer holding the archive.
This buffer is put into cpio-mode.
It holds all the "global" data,
like the catalog described above.
4. The buffer holding the dired-like UI.
cpio-mode creates this buffer and
puts this buffer into cpio-dired-mode.
5. Buffers visiting entries.
cpio-dired-mode uses the archive buffer
to get entry contents and them in the visiting buffer.
cpio-dired-mode puts that buffer in cpio-entry-contents-mode,
a minor mode that handles editing and saving
an entry's contents.
Naming conventions.
All files that define cpio-mode begin with "cpio."
Global variables all begin '*cpio-...'.
Functions are named 'cpio-...'.
The corresponding archive format specific names for format FMT
begin '*cpio-FMT-...' and 'cpio-FMT-...'.
The format-specific variables names are calculated
in (cpio-set-local-vars).
That function drops directly into corresponding format-specific functions
The format-specific function names are calculated
in (cpio-set-local-funcs).
Here is the process:
cpio-do-good-stuff-func
--> "cpio-do-good-stuff-func"
--> "cpio" "do" "good" "stuff"
--> "cpio-fmt-do-good-stuff"
--> cpio-fmt-do-good-stuff
The index of FIELD within a parsed header is named 'cpio-FIELD-parsed-idx'.
Each archive format FMT has a regular expression
that identifies that format unambiguously called '*cpio-FMT-header-re*'.
The functions (cpio-get-FIELD) operate directly on the header
to extract FIELD.
It's not clear that these need to be defined here.
The functions (cpio-FIELD) operate on a parsed header
to extract FIELD.
Depending on the context the expression "entry attributes",
often abbreviated "attrs", and the phrase "parsed header"
are used to reference the structure
that stores inode-like information (mode, size, user, etc.).
Truly, the expressions are semantically equivalent.
However, "parsed header" is used where the topic at hand is
the archive, and
"entry attributes" is used where the topic at hand is
the internal processing within cpio-mode.
An "entry" is, somewhat ambiguously, either an entry in the archive
or a member of the catalog.
The context should make it clear which is intended.
Yes, in principle they're isomorphic.
(And, yes, I hate specifications that depend on context.)