Holdon is a filter for UNIX command-line that enables users to control output, thus ensuring that only important information is displayed.
Holdon is a command line filter designed specifically for UNIX. Its function is to cache stdin until EOF, and then write it to a file designated in the command line. I discovered this useful tool while working on bbots. Before coming across Holdon, I had to work with bash, which makes it impossible to redirect to a file that is already in use in the pipeline. This can be due to the fact that the file is opened with O_TRUC, as soon as the programs are all launched simultaneously. This repeatedly made me perform tedious tasks, such as executing 'grep -v ${SOMEITEM} ${SOMELIST} > temp-file' followed by 'mv temp-file ${SOMELIST}'. This got very frustrating quickly. Obviously I've abstracted the list interaction away now, but that's not the only example.
Holdon simplifies this process greatly. In order to perform the above task with holdon, all that is required is to execute the following command: '$ grep -v ${SOMEITEM} ${SOMELIST} | holdon ${SOMELIST}'. As a result, the lines of code are much simpler, which makes it look a lot neater.
Something to bear in mind is that the buffer size has been hardcoded to 4096, which happens to be the page size for x86. If you use a different architecture, you will need to adjust this accordingly. The reason for this is that the SSIZE_MAX #define mentioned in the read() specification doesn't seem to exist on my system. Also, O_DIRECT doesn't exist on my system either, so I've included these definitions at the top of the file for your convenience if you should need to modify them.
I've been thinking about how to improve Holdon even further. Although the page size looks like a good allocation unit, it might not necessarily be the best option. Maybe including the meta-info from the memory allocator could be a more effective option? However, attempting to tune this could come at a cost, as a whole page would be solely dedicated to the buffer which would cost on the first allocation. Overall, Holdon is a fantastic tool that simplifies the command line process greatly.
Holdon simplifies this process greatly. In order to perform the above task with holdon, all that is required is to execute the following command: '$ grep -v ${SOMEITEM} ${SOMELIST} | holdon ${SOMELIST}'. As a result, the lines of code are much simpler, which makes it look a lot neater.
Something to bear in mind is that the buffer size has been hardcoded to 4096, which happens to be the page size for x86. If you use a different architecture, you will need to adjust this accordingly. The reason for this is that the SSIZE_MAX #define mentioned in the read() specification doesn't seem to exist on my system. Also, O_DIRECT doesn't exist on my system either, so I've included these definitions at the top of the file for your convenience if you should need to modify them.
I've been thinking about how to improve Holdon even further. Although the page size looks like a good allocation unit, it might not necessarily be the best option. Maybe including the meta-info from the memory allocator could be a more effective option? However, attempting to tune this could come at a cost, as a whole page would be solely dedicated to the buffer which would cost on the first allocation. Overall, Holdon is a fantastic tool that simplifies the command line process greatly.
What's New