Open xianglin1998 opened 4 years ago
Look, complex mixture.
Yes, not a new idea and its already in the pipe line, with the new preference
command.
In the next step we will enable a user to have a default save path for dumps, traces and configurable within the preference.json
file. see https://github.com/RfidResearchGroup/proxmark3/blob/master/client/src/preferences.c#L59 We are having a discussion about how to make it the nicest user experince, and how not to break expectations of a command execution when running from shell like ./pm3 -c 'data save xxxx'
Wow, It's a cool implementation. What can I do for you?
First is finishing the libpm3 branch. Which will unify how to call pm3 client. This will affect your current android implementation located at client/android
folder.
Then save paths or redirect printf calls will be addressed.
Found this "idea" when I was trying to figure out why pm3 with the version I pulled and compiled yesterday is for some reason always putting the files it generates at /home/username/
home folder instead of the current working directory where I run the command from.
This is really frustrating since I tend to make subfolders for the particular card I'm playing with that gives a human readable name and has other related stuff such as the dictionary I'm wanting to use.
For some reason I thought old versions used to use the current working directory instead of randomly shoving everything in the user's home folder without asking...which IMO is a very bad thing and confusing.
I believe you missed out on the preference command.
pref show
where you would be interested in
pref set savepaths -h
Another way is to edit the .proxmark3/preferences.json
file.
I believe you missed out on the preference command.
pref show
where you would be interested in
pref set savepaths -h
Another way is to edit the
.proxmark3/preferences.json
file.
That looks like it would let me pick one permanently but I don't see a way to un-set it so it'll use the current working directory?
if its empty it should use CWD, check the code paths to verify it.
if its empty it should use CWD, check the code paths to verify it.
Just tested, this works
I think it's very troublesome to put dump files and executable files together. In some cases, a good file path arrangement can make users happy, especially when deleting or compressing all dumps.
I recommend keeping the dump in a separate subdirectory, such as "/dumps" (when not installed) relative to the executable. Or relative to the user working directory.
: ) Thanks.