3.4-rc1: different behaviour for absolute paths in M98
-
Small call out because I couldn't find anything about it in the changelogs:
I'm now running Duet 2 with SBC and 3.4-rc1 firmware, DSF, DWC, etc.
I previously used to call macros and other sys gcode files with
M98 P"0:sys/partial-homez.g"
.With 3.4-rc1 this is no longer valid, because apparently the path was not absolute.
The now valid way of specifying the path is:M98 P"0:/sys/partial-homez.g"
.Not sure if my code just worked by accident in previous versions, or if this is a new change that is not documented yet?
-
@resam I've always had to use a full path, "/macros/PLAOffset", it couldn't find it without the "/macros/" or "/sys/". The 0: hasn't been needed.
-
@resam said in 3.4-rc1: different behaviour for absolute paths in M98:
my code just worked by accident in previous versions
I think so.
P"0:sys/
sticks out to me like a sore thumb. There's a drive call without a slash. -
@phaedrux I never thought about it... in my mind the
0:
served the same as/
to anchor a path to the "root".
Apparently I just got lucky for the last years. I'm using this on multiple places since at least 2019! -
@resam You are right, it should work in SBC mode as well since FatFs supports paths like
0:sys/foobar
. I'll fix it in v3.4-rc2. -
@chrishamm thanks!
just a small nitpick: this commit looks like that now the following paths are valid, is this intended, or were you looking for the
?
regex operator?0:asdf/foobar.bin 0:/asdf/foobar.bin 0:///////way/too/many/leading/slashes/foobar.bin
On second thought, the regex probably doesn't need the
/*
at all, it's already covered by the second group with.*
-
@resam It was a shorthand version to ignore double (or even triple) slashes which are also permitted by FatFs, see http://elm-chan.org/fsw/ff/doc/filename.html But I suppose having
/?/?
instead of/*
would also work.