proxmark3
proxmark3 copied to clipboard
RfidResearchGroup
User preferences: implement user preferred paths
Continuation of doegox/proxmark-internal#203
It implies probably fixing RfidResearchGroup/proxmark3#129 first and discuss here the exact user experience we'd like to see, in different scenarios.
Started work on the initial user preferred paths. for a sanity check, my approach is as follows. Phase 1 - for load calls.
- have an array of path pointers (this will allow for 1 or more paths and we can then loop through when searching for a file)
- update loadFileJSON, loadFileEML and loadFile to call searchFile (...) searchFile then (as is) calls searchFinalFile (...)
- At the bottom of searchFinalFile () i have added the code to loop through the paths array.
If at any point in the searchFinalFile, it finds the file, it will return with that match (i.e. first match). So, if the file is in the current working directory, that will be returned (order can be reviewed in phase 2).
- In the additional code -- if the first character is a "/" (e.g. /pm3/data) or the 2nd character is a ":" (e.g. d:\pm3\data) then it will assume its a full path, if not, it assumes its relative and prepends get_my_user_directory()
Hi @mwalker33 Beware we're chasing extra warnings in the "strict" branch which could impact merging. You can safely backport the changes from that branch for just the preferences.c file if you prefer to avoid difficulties later.
-
https://github.com/RfidResearchGroup/proxmark3/commit/3529aea157fdb488fef2371b4fffbfcace000ed1#diff-e8ac9c7a2a75b77b1e11a68be3f9f276
-
use (void)
-
use static
-
the strdup is because the returned value will be freed by the caller
For 2) please consider also path starting with ./ or .\ which will mean relative to the current working directory
No offence but again, before coding, I'd prefer to have a clear view of scenarios and agree on what we want as user experience before rather than trying to figure out user experience from the changes implemented in code.
Sorry lads.... works got me very busy atm. Did you have an eta for the "strict" to go live? Might pay to wait? Thanks.
strict branch is now "green" and @iceman1001 fixed some RPIZ warnings today so it should be good for merge, @iceman1001 ?
With all your fixes, its only down to "warnings" for cmdtrace.c which we are already chatting about.
Merge, go go go!
Don't forget I updated to BT manual in Master.
