EDIT: Never mind... when I'm reading the file, it's reading the content, not the path... duh!
Still, why isn't a "prepend to file" option available?
What am I missing here?
The macro works when I add the path directly to the "to file" field, but if I use a variable, I get:
Action 16247724 failed: Write File action failed because destination is not a full path (null)
Also (since this is related to this workflow):
Why isn't a "prepend to file" action, the same way we have "append to file"?
You can probably use an Execute Shell Command action to "prepend text" to a specific file, which would probably save you one action. There are several commands that should let you do this, but they can be tricky to write, while your way is simple. So stick with your method.
It might be that it's because appending text to a file is simple, but prepending text isn't as simple. As a comparison, in the shell, this is append:
echo "hello" >> existing_file.txt
And this is prepend:
A multi-page, 20+ answer discussion on the various alternatives, none of which are anywhere near as simple as the append solution. Why is it more difficult to prepend?
Because from a technical perspective, you have to shift all the existing content "down" to make room for the new content above it. One way to do that is to store the new content in a temporary file (or memory), then append the original file's content to it, and then write the newly-combined data to the existing file.
Contrast that with appending, which requires just adding the new content to the end of the existing content, which requires no moving of data.
With a prepend operation, a lot could go wrong, especially if it's a massive file and you run into RAM limitations. Perhaps this is why prepending to a file isn't an option in Keyboard Maestro, but only Peter could say for certain.
thank you so much for the detailed reply!
I already saved this as a favorite "action" so I can use it in the future.
It's interesting how something so simple to understand in our brain, is so complex when we try to translate it to computer language.
and this, my friend, is why I still think that underestimating the power of the human brain when compared to machines, is not the right way to evolve and make both work together, it's not "this is better than that". they just serve different purposes
Imagine you'd started writing at the very top of a piece of paper, got half-way down, then realised you needed to add another line at the very beginning. Realistically you've two choices:
Grab a fresh piece of paper, with down your new first line at the top, then copy each line from the old paper to the new one.
Grab a small piece of paper, write your new line on that, then Sellotape it to the top of the old piece
And the KM version of either of those might be:
You can see from the above that, as @griffman says, the bigger the file you want to add to the more expensive this gets because you have to both read it all in and write it all out again -- just to add a single line. There's a reason log files are built by adding lines to the end and not the beginning!
I totally understand that. My comment was just related to how amazing our brain is. We can easily understand what needs to be done and how, but for a computer, it's a more complex task. To our brain, we only see it as "where does this information go?" We don't see it as being more complex to add it to the top.
That's why I find it interesting and at the same time amazing. After all, we are just dealing with electricity being ON or OFF, right? It still melts my brain thinking how everything works, how things are stored, etc. But that's a whole different topic...
But wouldn't it be possible to create an action that would wrap this workflow? So instead of us having to create 2 actions, wouldn't it be possible to have an action that does the same thing under the hood? I'm asking, because I have no idea how Keyboard Maestro is built, code-wise.
It would, but as I theorized above, there are many more risks involved, because you could be dealing with tons of data in RAM, or writing to temporary files. If any of those steps go wrong, the data could be lost.
Yes, you risk the same thing yourself when you write your own solution, but then if something goes wrong, it's with something you wrote ... that's a lot easier to explain than something in the code causing you to lose your data.
At least, that's how I'd see it: The risk of implementing the feature has to be weighed against the risks. Appending is easy; prepending is not :).
