Post Rename Reference

[Raptor6L]

Hi Rednoah

It's taken a while to figure it out but I've got your AMC script working as the part of a larger process. Pretty neat!
I'm wondering if there is a way to reference the file\ folder after AMC has renamed it?
Example: AMC sees the title from qbt using this reference "ut_title=%N", but "ut_title=%N" remains the original (old) title.

Thanks
Raptor6L

[rednoah]

The -exec custom post-process commands manual is a good way to get started with custom post-process commands.


e.g.

Shell: Select all

-exec /path/to/script.sh {f} {historic.f} {json}

{f} is the new file path
{historic.f} is the previous file path
{json} is the xattr metadata


"ut_title=%N" is notably not the file name / file path. %N typically refers to the download name which may or may not be the same as the actual file name / directory name. The ut_title variable is notably largely unused by the amc script but we do pass it along in all the examples because there's no reason not to. You can access that field from your format / exec / etc expression via the {defines.ut_title} binding.

[Raptor6L]

The -exec custom post-process commands manual is a good way to get started with custom post-process commands.


e.g.

Shell: Select all

-exec /path/to/script.sh {f} {historic.f} {json}

{f} is the new file path
{historic.f} is the previous file path
{json} is the xattr metadata

Excellent, that I can have a play with.

Thank you again!

[Raptor6L]

Hi RedNoah

Life's been busy but I've recently had time to come back to this. I can see the below command is now showing me the filepath in the logs:

Shell: Select all

filebot -script fn:amc ... --def exec="echo {quote f}"

I run your AMC script from a bash script and I'm trying to get that filepath back into my bash script.
Am I able to "Set" {quote f} to something like %newpath%, within your AMC script?
The idea being once your AMC script has finished, my bash script can continue on and use %newpath% when referring to that {quote f} filepath.

Hope that makes sense.

Thanks
Chris

[rednoah]

I run your AMC script from a bash script and I'm trying to get that filepath back into my bash script.

AFAIK, a process called by your bash script (i.e. filebot) fundamentally cannot modify (i.e. write back variables) to the parent process.


What exactly do you need to do? Why pass information back to your bash script, instead of just acting on that information right when your --def exec command is called?


In any case, you can always build your own solution. You will find may solutions here in the forums (since it's a common use case) and your preferred coding LLM might have some good ideas as well.


e.g. (A) write output file paths to a file and then read that from your bash script after filebot is done:

Shell: Select all

filebot -script fn:amc ... --def exec="echo {quote f} >> /tmp/filebot.out"

e.g. (B) parse the entire output of the filebot call directly from your bash script:

Shell: Select all

export FILEBOT_OUT=""
source <(
  filebot -script fn:amc ... --def exec="echo 'export FILEBOT_OUT=\"\$FILEBOT_OUT{f}\\\\n\"'" | egrep "^export FILEBOT_OUT="
)
echo $FILEBOT_OUT

** somewhat untested; you might need to figure out the correct use of " and ' and \ and $ in a nested nested nested command template yourself; AFAIK this is the only way if you really really must have your bash script set variables in your bash script context from the filebot command output... but it's an abomination and you should never do it like this


e.g. (C) make your -exec command do whatever you need to do instead of passing paths back to your bash script and then doing that:

Shell: Select all

filebot -script fn:amc ... --def exec="/path/to/script.sh {quote f}"

IMHO, Option C is by far the most clean option and naturally works even if you process more than one file.

[Raptor6L]

Hi RedNoah

AFAIK, a process called by your bash script (i.e. filebot) fundamentally cannot modify (i.e. write back variables) to the parent process.

yeah, that's where my thoughts were leading to as well, but thought I'd ask anyway.

What exactly do you need to do? Why pass information back to your bash script, instead of just acting on that information right when your --def exec command is called?

So, first up, I'm fully aware my situation is not the norm - I'm probably in the 1% with the way I have my stuff set up, but it works for me nonetheless.

My file server is on a different system to the vm I'm running filebot on. My file server, for a few different reasons, is not up 24/7, but the vm that filebot is on is running 24/7.
I run filebot off a cmd script (apologies - i've referred to it as a bash script, when it actually isn't. It's a cmd script.) because not everything I run through the vm needs to go to filebot, so this cmd script filters out those files and redirects them where they need to go, and the rest goes to filebot.
For the files that do need to go to filebot, I've found that if my file server is not available (and therefore the --output location is not available) then the process fails and the file\folder does not get renamed and none of the metadata is gathered etc etc.
To combat this, I've got the --output location on the same vm as filebot. That way, even if the file server is down, filebot is still able to carry out all its duties.

What I'm trying to do here is get the new folder name and location so after filebot is done, the cmd script can trigger robocopy to move the folder to the fileserver location (if it's available). If that fails because the fileserver is down, that's fine, at least filebot has done its job.

e.g. (A) write output file paths to a file and then read that from your bash script after filebot is done:

Shell: Select all

filebot -script fn:amc ... --def exec="echo {quote f} >> /tmp/filebot.out"

This will work for me, except I'm having some troubles quoting the original title the echo is going to because it has spaces in it.
The destination you used in your example above is /temp/filebot.out - no spaces so no need for quotes.
The destination I'm using is T:/FileBot/Logs/%title%.txt which stops once it comes to the first space within the title.

I've tried several methods including literal double quoting, or using a variant that results in double quoting:

filebot -script fn:amc ... --def exec="echo {quote f} >> "T:/FileBot/Logs/%title%.txt""

Using single quote marks instead of both being double, both ways:

filebot -script fn:amc ... --def exec="echo {quote f} >> 'T:/FileBot/Logs/%title%.txt'"

filebot -script fn:amc ... --def exec='echo {quote f} >> "T:/FileBot/Logs/%title%.txt"'

Using braces:

filebot -script fn:amc ... --def exec="echo {quote f} >> {T:/FileBot/Logs/%title%.txt}"

With that last one I found the link to the arguments parsing in the forums, which led me to try using \ escapes:

filebot -script fn:amc ... --def exec="echo {quote f} >> \"T:/FileBot/Logs/%title%.txt\""

I then tried it with just a made up file name instead of the %title% variable to prove to myself it wasn't the variable:

filebot -script fn:amc ... --def exec="echo {quote f} >> \"T:/FileBot/Logs/A Made Up File Name (2018).txt\""

Some of these didn't make a file at all. None of these made a .txt file. Some of them made a file but the file name stopped at the first space.

This did exactly what it was supposed to, but as you can see, there are no spaces in the filename:

filebot -script fn:amc ... --def exec="echo {quote f} >> T:/FileBot/Logs/File.txt"

The File.txt was created and it had the new folder and file location in it, which is almost perfect, except the txt file is not the same name as the original file name.

Have you got any suggestions on how to quote the txt file name?

Thanks
Chris

[rednoah]

Your doing this on Windows!? With Windows CMD no less!? I don't usually use emoji... but...


Alright, lets say this work for you, so we can start with this:

Shell: Select all

filebot -script fn:amc ... --def exec="echo {quote f} >> T:/FileBot/Logs/File.txt"

You also have a variable %title% in your CMD script context that you want to pass onto FileBot to be used as part of the --def exec command.


Rather than fighting CMD with a dynamically generated --def exec value, you could also just pass the value along via a generic --def name=value FileBot variable and then use that in your --exec expression:

Shell: Select all

filebot -script fn:amc ... --def exec="echo {quote f} >> {quote defines.myLogFile}" --def myLogFile="T:/FileBot/Logs/%title%.txt"

You could also follow the same approach but use a system environment variable instead of a FileBot variable:

Shell: Select all

set "myLogFile=T:/FileBot/Logs/%title%.txt"
filebot -script fn:amc ... --def exec="echo {quote f} >> {quote System.env.myLogFile}"

[Raptor6L]

Your doing this on Windows!? With Windows CMD no less!? I don't usually use emoji... but...

Haha, yep! It's the only bit of Windows left in my server environment. I'll no doubt make a move away from it at some point, but I'm not there yet.
In the meantime, I'll bask in the gentle glow of your rarely used emoji!

Alright, lets say this work for you, so we can start with this:

Shell: Select all

filebot -script fn:amc ... --def exec="echo {quote f} >> T:/FileBot/Logs/File.txt"

You also have a variable %title% in your CMD script context that you want to pass onto FileBot to be used as part of the --def exec command.

Rather than fighting CMD with a dynamically generated --def exec value, you could also just pass the value along via a generic --def name=value FileBot variable and then use that in your --exec expression:

Shell: Select all

filebot -script fn:amc ... --def exec="echo {quote f} >> {quote defines.myLogFile}" --def myLogFile="T:/FileBot/Logs/%title%.txt"

Ok, so I've tried this and it hasn't worked. I've actually tried several iterations. Some have created a file that wasn't a .txt file and it was named the first word of the title - so halted at the first space it came to. Others didn't create a file at all.

Title (and %title%) is Elizabeth The Golden Age (2007) [1080p]

--def exec="echo {quote f} >> {quote defines.myLogFile}" --def myLogFile="T:/FileBot/Logs/Elizabeth The Golden Age (2007).txt"

--def exec="echo {quote f} >> {quote defines.myLogFile}" --def myLogFile="T:/FileBot/Logs/%title%.txt"

Both of these resulted in no file being created and the exact same entry in the log:

Execute: echo @'
T:\FileBot\READY\Elizabeth The Golden Age (2007)\Elizabeth The Golden Age (2007).mp4
'@ >> @'
T:/FileBot/Logs/Elizabeth The Golden Age (2007) [1080p].txt
'@
out-file : Cannot perform operation because the wildcard path T:/FileBot/Logs/Elizabeth The Golden Age (2007) [1080p].txt
did not resolve to a file.

Another attempt but this time I used double quotations:

--def exec="echo {quote f} >> {quote defines.myLogFile}" --def myLogFile=""T:/FileBot/Logs/%title%.txt""

With this one, a file is created, but it isn't a .txt file, and it isn't the full name.
Log entry:

Execute: echo @'
T:\FileBot\READY\Elizabeth The Golden Age (2007)\Elizabeth The Golden Age (2007).mp4
'@ >> @'
T:/FileBot/Logs/Elizabeth
'@

So, it's falling over at the first space it comes to.
Interestingly, if I convert that file to a .txt, it has the correct info inside.

This time I put the space in the address rather than the file name. T:/File Bot/Logs instead of T:/FileBot/Logs:

--def exec="echo {quote f} >> {quote defines.myLogFile}" --def myLogFile=""T:/File Bot/Logs/%title%.txt""

Result is a file called "file" at T:/

Execute: echo @'
T:\FileBot\READY\Elizabeth The Golden Age (2007)\Elizabeth The Golden Age (2007).mp4
'@ >> @'
T:/File
'@

Any ideas?

Chris

[rednoah]

Looks like PowerShell doesn't like [...] in >> file paths...

Try this:

Shell: Select all

filebot -script fn:amc ... --def exec="Add-Content -LiteralPath {quote defines.myLogFile} -Value {quote f}" --def myLogFile="T:/FileBot/Logs/%title%.txt"

** using -LiteralPath instead of -Path is the key here

[Raptor6L]

Looks like PowerShell doesn't like [...] in >> file paths...

Try this:

Shell: Select all

filebot -script fn:amc ... --def exec="Add-Content -LiteralPath {quote defines.myLogFile} -Value {quote f}" --def myLogFile="T:/FileBot/Logs/%title%.txt"

** using -LiteralPath instead of -Path is the key here

Winner winner chicken dinner!!!

Thanks RedNoah! Appreciate your time and efforts!