DOS APPEND, similar to the PATH command, allows you to specify directories where DOS should search for data files, not just executable files. This lets programs access data in various locations without needing full path specifications. It supports both drive letters and network paths, and offers options to search appended directories before the current directory or to treat appended directories as subdirectories of the current one. APPEND also provides commands to display the current appended directories and to remove them. This expands the functionality beyond the simple executable search of PATH, making data access more flexible.
The blog post "DOS APPEND" from the OS/2 Museum meticulously details the functionality and nuances of the APPEND command in various DOS versions, primarily focusing on its evolution and differences compared to the PATH command. APPEND, much like PATH, allows programs to access data files located in directories other than their current working directory. However, while PATH focuses on executable files, APPEND extends this capability to data files, specified by various file extensions.
The article begins by explaining the initial purpose of APPEND in DOS 3.3, highlighting its ability to search specified directories for data files when a program attempts to open a file not found in the current directory. This eliminates the need for programs to explicitly handle path information for data files. The post then traces the development of APPEND through later DOS versions, including DOS 3.31, where a significant bug related to networked drives was addressed.
A key distinction between APPEND and PATH is elaborated upon: PATH affects only the search for executable files (.COM, .EXE, and .BAT), while APPEND pertains to data files with extensions specified by the user. This difference is crucial for understanding their respective roles within the DOS environment.
The blog post further delves into the various ways APPEND can be used, outlining the command-line switches and their effects. These switches include /E, which loads the appended directories into an environment variable, /PATH:ON, which enables searching the appended directories even when a full path is provided for a file, and /PATH:OFF, which disables this behavior. The post also explains the use of /X, which extends the functionality of APPEND to affect the EXEC function calls, thus influencing child processes.
The evolution of APPEND continues to be discussed, noting the removal of the problematic /X:ON and /X:OFF switches in later versions due to their instability. The article also touches upon the differences in behavior between APPEND in MS-DOS/PC DOS and DR DOS, particularly concerning the handling of the ; delimiter in the APPEND list and the search order when multiple directories are specified.
Finally, the post concludes by briefly discussing the persistence of APPEND in later Windows versions for compatibility, even though its utility diminishes in these more advanced operating systems with their more sophisticated file management capabilities. The article thoroughly explores the intricacies and historical context of the APPEND command, offering a comprehensive understanding of its functionality and its place within the broader DOS ecosystem.
Summary of Comments ( 56 )
https://news.ycombinator.com/item?id=42475011
Hacker News users discuss the DOS
APPENDcommand, primarily focusing on its obscure nature and surprising functionality. Several commenters recall struggling withAPPEND's unexpected behavior, particularly its ability to make files appear in directories where they don't physically exist. The discussion highlights the command's similarity to environment variables likePATHandLD_LIBRARY_PATH, with one user pointing out that it effectively extends the file search path for specific programs. Some comments mention the utility ofAPPENDfor accessing data files across drives or directories without hardcoding paths, while others express their preference for more modern solutions. The overall sentiment suggestsAPPENDwas a powerful but complex tool, often misunderstood and potentially problematic.The Hacker News post titled "DOS APPEND" with the link https://www.os2museum.com/wp/dos-append/ has several comments discussing the utility of the
APPENDcommand in DOS and OS/2, as well as its quirks and comparisons to other operating systems.One commenter recalls using
APPENDfrequently and finding it incredibly useful, particularly for accessing data files located in different directories without having to constantly change directories or use full paths. They highlight the convenience it offered in a time before sophisticated development environments and integrated development environments (IDEs).Another commenter draws a parallel between
APPENDand the modern concept of environment variables like$PATHin Unix-like systems, which serve a similar purpose of specifying locations where the system should search for executables. They also touch on howAPPENDdiffered slightly in OS/2, specifically regarding the handling of data files versus executables.Further discussion revolves around the intricacies of
APPEND's behavior. One comment explains howAPPENDdidn't just search the appended directories but actually made them appear as if they were part of the current directory, creating a virtualized directory structure. This led to some confusion and unexpected behavior in certain situations, especially with programs that relied on obtaining the current working directory.One user recounts experiences with the complexities of managing multiple directories and files in early versions of Turbo Pascal, illustrating the context where a tool like
APPENDwould have been valuable. This comment also highlights the limited tooling available at the time, emphasizing the appeal of features likeAPPENDfor streamlining development workflows.Someone points out the potential for conflicts and unexpected results when using
APPENDwith programs that create files in the current directory. They suggest thatAPPEND's behavior could lead to files being inadvertently created in a directory different from the intended one, depending on how the program handled relative paths.The security implications of
APPENDare also addressed, with a comment mentioning the risks associated with accidentally executing programs from untrusted directories added to theAPPENDpath. This highlights the potential security vulnerabilities that could arise from misuse or improper configuration of the command.Finally, there's a mention of a similar feature called
apppathin the REXX language, further illustrating the cross-platform desire for this kind of directory management functionality.Overall, the comments paint a picture of
APPENDas a powerful but somewhat quirky tool that provided a valuable solution to directory management challenges in the DOS/OS/2 era, while also introducing potential pitfalls that required careful consideration. The discussion showcases howAPPENDreflected the computing landscape of the time and how its functionality foreshadowed concepts that are commonplace in modern operating systems.