MarkW
Member
A quick question. Is it possible to write to the users real home directory from within the run script of a pnd? Initial attempts fail with a permissions error - just need to check that there isn't a way that I'm not using.
Pandora Writing to $HOME (the real one) from a pnd
- Thread starter MarkW
- Start date
- Status
sebt3
homebrew player (P. & C.)
there is a REAL_HOME env variable that point out there 
MarkW
Member
Yes it points there, but I cannot seem to write to it (I only want to place a sym-link there)!there is a REAL_HOME env variable that point out there
sebt3
homebrew player (P. & C.)
Hum strange. That should'nt be the case as nothing is done against that.Log output plz ?
MarkW
Member
Hang on, I'll have to put that bit of script back in!!!! Be back in 5!
MarkW
Member
Damm :rolleyes: !
I was using $REALHOME - if I use the correct variable name ($REAL_HOME) - it works just fine. I need to get my eyes fixed.
sebt3
homebrew player (P. & C.)
Every one sometime need an other pair of eyes to see that kind of issues. The board is there for that
- Joined
- Dec 8, 2005
- Messages
- 6,603
- Age
- 40
- Location
- UK
- Website
- pokeparadox.itch.io
- WEBSITE
- https://github.com/pokeparadox
- YOUTUBE
- pokeparadox
LOL it sounds like a mass shunning?
Wouldn't it be better to say "So people know about it in case it's an issue for them." or something like that?
MarkW
Member
Sure, I'll just let the software write a whole bunch of files to your NAND instead. Would you prefer that or a single sym-link?
levi
Still fresh, damnit!
Well, if you explained why you needed to write that symlink to my home directory, I might let you. But on my Pandora, unlike on my other Linux boxes, I never look in my home directory for anything (since everything's on my SD cards), and neither does any Pandora-specific software.
ZXDunny
Deep avatar
- Joined
- Oct 12, 2010
- Messages
- 2,585
What happens to the symlink when I eject my SD card? There are some PNDs that I allow to write to NAND - the Timidity installer, for instance. But those are very few and far between.
It's tremendously bad form to write to NAND without a very, very good reason - so what's yours?
Not being confrontational - genuinely interested.
D.
MarkW
Member
Gnu Backgammon wants to place its configuration files there - which are updated after each game/match. To save multiple NAND writes, I pre-install the configuration files to appdata, and then put a sym-link in HOME to ensure the appdata files are used and not re-created with a crap screen layout elsewhere.
What happens when you eject the card? The symlink is still there, it just can't be honoured. Put your card back in, and off you go. The Sym link is honoured, even if you use the other slot.
The only thing that will FUBAR the link is if you re-label your card.
ptitSeb
Serial Porter
Just curious: why don't you use the "appdata" home for the saves. Why using the real_home and a symlink to the SDCard? I'm confused here (the only benefit I see using real_home is to be sure to have an Linux File System, but than the use of the symlink doesn't fit).
*EDIT*
May be be you can use the home appdata folder. Check if it's present. If not, create him and populate him with your data at start (that's what I have done a few times to bring default config files).
*EDIT*
May be be you can use the home appdata folder. Check if it's present. If not, create him and populate him with your data at start (that's what I have done a few times to bring default config files).
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Why does it want to write configuration files there? Why isn't it writing them to $HOME which is on the SD card? That's the very reason why the $HOME variable is changed, so that it won't write to the NAND when it can just as easily write to the SD card.
mcobit
Advanced Member
- Joined
- Jul 28, 2008
- Messages
- 6,909
Could be that it uses something like gGetHomeDir().
Afaik this is the only thing that cannot be redirected right now by the pnd system.
Look through the code for the appearences of that function and replace it with the /mnt/utmp/yourapp dir.
Or just getenv(HOME).
Afaik this is the only thing that cannot be redirected right now by the pnd system.
Look through the code for the appearences of that function and replace it with the /mnt/utmp/yourapp dir.
Or just getenv(HOME).
Perhaps an explanatory note is called for here, since Mark hasn't been around for very long:
We've had massive discussions in the past about writing to the NAND or not. Huge ones, with a very highly strung tension, where people have accused each other of bullying or sneaking or secretly conspiring to do this or that. It has been a rather inflamed topic, it has.
The fallout at the end was something like this:
1) The NAND is a precious thing. It gets filled up rather quickly, and it might actually wear out from overuse (not in a resonable timeframe, but still - It might). We want to take good care of the NAND.
2) The point of the PND system is to isolate things from each other, in a way. When you put a PND on an SD card, it is with the silent assumption that the PND affects nothing outside that SD card, unless there are very compelling reasons for it to do so. When you delete the PND and the appdata for that PND, there ought to be no traces of that PND left.
Therefore, the Right Thing is to not let a PND write to the NAND, but to redirect all writes to the appdata dir. That is the generally accepted Right And Proper Way.
A side effect from the debates is that since the subject got so infected, it is still kinda touchy. Do mention the war, by all means, but don't mention the NAND. If you look way back in the archives, you'll find threads where people accuse each other of sneaking in "killer PNDs" by subterfuge, and requests that no PND be allowed on the repo unless it can be shown not to write to the NAND, and someone who got to be in the firing line for a his stance on this ("You are all a bunch of weak-wristed sissies, and I'll rather take all my work down than answer any questions about the NAND") retaliating by going through the repo and checking every PND and publishing "lists of shame" of PNDs other than his own which also did this, and...And so on.
Which means that when you, presumably rather innocently, pop in to ask a question about how you'd let a pnd write to the real ~, without say what PND and why, you kinda step in a hornets nest that has just been lying hidden there. All the oldtimers know not to step on it, but noone has put up a warning sign
So: Don't be to discouraged by the rather violent reactions to your question. They're not really directed at you
We've had massive discussions in the past about writing to the NAND or not. Huge ones, with a very highly strung tension, where people have accused each other of bullying or sneaking or secretly conspiring to do this or that. It has been a rather inflamed topic, it has.
The fallout at the end was something like this:
1) The NAND is a precious thing. It gets filled up rather quickly, and it might actually wear out from overuse (not in a resonable timeframe, but still - It might). We want to take good care of the NAND.
2) The point of the PND system is to isolate things from each other, in a way. When you put a PND on an SD card, it is with the silent assumption that the PND affects nothing outside that SD card, unless there are very compelling reasons for it to do so. When you delete the PND and the appdata for that PND, there ought to be no traces of that PND left.
Therefore, the Right Thing is to not let a PND write to the NAND, but to redirect all writes to the appdata dir. That is the generally accepted Right And Proper Way.
A side effect from the debates is that since the subject got so infected, it is still kinda touchy. Do mention the war, by all means, but don't mention the NAND. If you look way back in the archives, you'll find threads where people accuse each other of sneaking in "killer PNDs" by subterfuge, and requests that no PND be allowed on the repo unless it can be shown not to write to the NAND, and someone who got to be in the firing line for a his stance on this ("You are all a bunch of weak-wristed sissies, and I'll rather take all my work down than answer any questions about the NAND") retaliating by going through the repo and checking every PND and publishing "lists of shame" of PNDs other than his own which also did this, and...And so on.
Which means that when you, presumably rather innocently, pop in to ask a question about how you'd let a pnd write to the real ~, without say what PND and why, you kinda step in a hornets nest that has just been lying hidden there. All the oldtimers know not to step on it, but noone has put up a warning sign
So: Don't be to discouraged by the rather violent reactions to your question. They're not really directed at you
Last edited by a moderator:
MarkW
Member
Moxie - thank you for taking the time to write your response. I was sorely tempted to shoot from the hip, but walked away instead. And somebody needs to fix that warning sign.
GNU backgammon insists on writing to the true home - as far as I can figure. Hence the approach taken - writing a single sym link to NAND did not seem like a capital offence - and it still doesn't to me. There is no smoke and mirrors - the run.sh script is clearly visible.
If anyone would like to test the need for this approach, simply delete the sym link that will be created by the first run of the GNU Backgammon pnd, and then re-launch the pnd. Gnu Backgammon will start (because the test in the if construct will pass - due to .gnubg directory being present in appdatadir) - but guess what - new configuration files will be created in the real home (inside a newly created .gnubg directory). This is not done by my run.sh script. The configuration files copied to appdatadir on first launch will be completely ignored - and not even be referenced. The only way they get referenced is by taking the approach I have used. So, as far as I can tell, whilst home may be re-mapped, it is not 100% effective in preventing NAND writes - although I'm quite happy to be corrected on this.
A number of pnds in the repo just let the software they contain write to NAND without a care in the world (some I have re-packaged myself to stop this, others I have dealt with using sym links), and the authors make no attempt to stop such writes. Neither do the authors seem to be castigated for the their approach. However, it was to stop multiple writes that I took the approach I did. If this is such a hot potato - and no, I am NOT going to search back through years of flame wars to find the history (I have neither the time nor the inclination) - I suggest that this approach be very strongly discouraged in the documentation - perhaps with warnings of terminal action if the guidelines are transgressed). I do read it the documentation.
I suspect I have re-ignited something here. So be it. Telepathy is not one of my claimed skills.
GNU backgammon insists on writing to the true home - as far as I can figure. Hence the approach taken - writing a single sym link to NAND did not seem like a capital offence - and it still doesn't to me. There is no smoke and mirrors - the run.sh script is clearly visible.
If anyone would like to test the need for this approach, simply delete the sym link that will be created by the first run of the GNU Backgammon pnd, and then re-launch the pnd. Gnu Backgammon will start (because the test in the if construct will pass - due to .gnubg directory being present in appdatadir) - but guess what - new configuration files will be created in the real home (inside a newly created .gnubg directory). This is not done by my run.sh script. The configuration files copied to appdatadir on first launch will be completely ignored - and not even be referenced. The only way they get referenced is by taking the approach I have used. So, as far as I can tell, whilst home may be re-mapped, it is not 100% effective in preventing NAND writes - although I'm quite happy to be corrected on this.
A number of pnds in the repo just let the software they contain write to NAND without a care in the world (some I have re-packaged myself to stop this, others I have dealt with using sym links), and the authors make no attempt to stop such writes. Neither do the authors seem to be castigated for the their approach. However, it was to stop multiple writes that I took the approach I did. If this is such a hot potato - and no, I am NOT going to search back through years of flame wars to find the history (I have neither the time nor the inclination) - I suggest that this approach be very strongly discouraged in the documentation - perhaps with warnings of terminal action if the guidelines are transgressed). I do read it the documentation.
I suspect I have re-ignited something here. So be it. Telepathy is not one of my claimed skills.
skeezix
Internal Development
Fix the code to write to current-dir ./ instead; probably only need change 1-2 functions..
Why sweat it? Or is the code impenetrable?
If the code is beyond you .. Ask for help rather than a drive-by port? But failing that just go abead as planned and leave a note in the px .. If someone disagreees, they can port it
Anyway, yeah .. Some folks come a ross rough; don't sweat it
Jeffphone
Why sweat it? Or is the code impenetrable?
If the code is beyond you .. Ask for help rather than a drive-by port? But failing that just go abead as planned and leave a note in the px .. If someone disagreees, they can port it
Anyway, yeah .. Some folks come a ross rough; don't sweat it
Jeffphone
- Status
