Refresh on Windows does a bunch of different things depending on the application. If you're talking about the file manager — reloading/refreshing is needed in some cases (and does the same thing as in Windows), but not that often.
Most modern desktop environments on *nix make use of either the inotify facility, or, for older ones, the File Alteration Monitor daemon famd
. You fire the appropriate system calls or connect to the famd
, give them a list of directories or files to watch, and you get you an asynchronous message when they change. For directories, you can get separate messages for when contents are added, deleted, changed, etc. Using this, a file manager can automatically refresh its view of a folder when the folder changes, and it's very easy to implement.
Think of it as a bot that hits F5 for you when it's needed.
You can see this in action yourself! Open your Downloads
folder in a file manager, then download a file with your web browser. The file manager will show the file automagically. If it's a big file (or a slow connection), you might even see the filename.part
temporary file appearing, then increasing in size, then getting renamed into the final filename
.
Modern file selection dialogue boxes do the same: if you go to ‘Open…’ and move a file into the directory the dialogue box is showing, that file will appear there immediately (not when you hit refresh).
Refreshing/reloading is still needed in a number of cases:
- If for some reason, you're running neither a modern kernel nor
famd
(e.g. old installation, embedded machine).
- If your files/entities are accessible over a medium
inotify
and famd
don't support because it's not a locally accessible ‘directory’, e.g. the GNOME VFS using sftp
or the KDE sftp://
IOSlave.
- If they're not files at all. For instance, web pages or documents being viewed. But: many viewers will watch their open files for changes and will automatically reload them. This is handy in development where you have a lot of edit-save-‘compile’-view cycles — the venerable
xdvi
did this for LaTeX typesetting. The KDE document reader okular
does it too.
The circumflex (^
) was equated to the up-arrow character on teleprinters. By the time SunOS and so forth came around, this part was more than 10 years in the past. The same character (replacement) was used in mathematical expressions, e.g., ^
for powers (where some others might use **
). It was also used in Pascal to indicate pointers.
Used for indicating control characters, this dates (at least) before 1980. You can find it used in DEC documentation for instance (it was certainly in use by the mid-1970s when I used teco. The Utilities manual from 1973 (page 927) shows a controlC for instance.
Looking for a suitable source, I find Teletypewriter Communication Codes by Gil Smith which says enough to place this in the late 1960s (demonstrating that the origin is pre-Unix, as well):
ASCII-63 was mostly identical to the current ASCII-67 version. The definitions of the control characters (col-1
above) varied between the two versions, as defined below. Also, in ASCII-63, the upper 32 positions (col-4) were
undefined, except for three: RUB (0x7F), ACK (0x7C), and ESC (0x7E). There are inconsistent references to an
ALT-MODE char (0x7D) in ASCII-63. In the 1967 version, RUB became DEL and stayed in the same position,
but ACK and ESC moved into the control character area (col-1). In ASCII-67, ^ replaced the up-arrow symbol,
and _ replaced the left-arrow
ASCII-63 and ASCII-67 are the common variants of ASCII, but there appear to have been some transitional
versions as well: in the Teletype Model 33 manual, there are references to a 1965 version of ASCII, that had SS in
place of SUB (0x1A), \ for @ (0x40), ~ for \ (0x5C), an odd character in place of | (0x7C), and | for ~ (0x7E). A
Teletype code card for M33 and M35 machines indicates a 1966 version of ASCII, though the printable characters
shown on the card were identical in all versions.
This used to be well-known, due to the problems of interchanging files between different encodings such as ASCII and EBCDIC where there were still printers capable of rendering up-arrows as such long after the character no longer existed in ASCII.
Best Answer
The terminal description is named for Linux, which provides its own console emulator (as do several other kernels).
Except for FreeBSD, all of the Linux- and modern BSD-platforms get "termcap" by deriving it from the terminfo database in ncurses. Console entries are specific to the systems in which they are implemented (unlike many terminal emulators, which run on more than one platform).
A comment in ncurses 1.8.6 (October 1994) for the
linux
terminal description stated:That was specific to Linux, but generalization followed as ncurses was ported.
In the ncurses sources, this section of
INSTALL
is very old (seen in 1.9.7a in November 1995), but not outdated:There is a section in the terminal database for these: ANSI, UNIX CONSOLE, AND SPECIAL TYPES, while there is no "vt-generic" description nor (given the differences across the variations), is there a plausible choice.
If you look for "vt-generic", likely you will find that only in less prevalent implementations such as Informix (seen in this file):
Further reading:
tctest
— termcap library checker