get user's home

classic Classic list List threaded Threaded
19 messages Options
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

get user's home

db
How can I get the user's home, the flesh and blood bot's?

set home            $::env(HOME)

righteously returns /opt/local/var/macports/home/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Joshua Root-8
On 2017-8-4 22:19 , db wrote:
> How can I get the user's home, the flesh and blood bot's?
>
> set home            $::env(HOME)
>
> righteously returns /opt/local/var/macports/home/

Should be in $user_home (if it could be determined, which is not
guaranteed). But why do you need it? The user installing the port is not
necessarily the one that will use it.

- Josh
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

db
On 4 Aug 2017, at 16:05, Joshua Root <[hidden email]> wrote:
> Should be in $user_home (if it could be determined, which is not guaranteed). But why do you need it? The user installing the port is not necessarily the one that will use it.

That worked, thanks. I used it for an env var's default value in ipfs' startup item (#54566). I don't know if we could pass a different value on install or load, for that matter. Everything's fine as in works_for_me. How come schraderbräu has it and macports not?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Stephen J. Butler
If this is a system level daemon that's being started, then it seems to me that it should be storing its data in a system level location. /opt/local/var/ipfs or /opt/local/var/lib/ipfs or /opt/local/var/spool/ipfs depending on various preferences.

On Fri, Aug 4, 2017 at 2:41 PM, db <[hidden email]> wrote:
On 4 Aug 2017, at 16:05, Joshua Root <[hidden email]> wrote:
> Should be in $user_home (if it could be determined, which is not guaranteed). But why do you need it? The user installing the port is not necessarily the one that will use it.

That worked, thanks. I used it for an env var's default value in ipfs' startup item (#54566). I don't know if we could pass a different value on install or load, for that matter. Everything's fine as in works_for_me. How come schraderbräu has it and macports not?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Umesh Singla-2
In reply to this post by Joshua Root-8
On a side note, I didn't get this part:

The user installing the port is not necessarily the one that will use it.
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Stephen J. Butler
For example, suppose I work in IT and someone needs ipfs on their machine. I might SSH in, run "sudo port install ipfs", and then say "All done!" But I'm not the one that will use that software, so it's not proper to encode my username anywhere as a default.

On Fri, Aug 4, 2017 at 3:46 PM, Umesh Singla <[hidden email]> wrote:
On a side note, I didn't get this part:

The user installing the port is not necessarily the one that will use it.
 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Joshua Root-8
In reply to this post by Umesh Singla-2
On 2017-8-5 06:46 , Umesh Singla wrote:
> On a side note, I didn't get this part:
>
>     The user installing the port is not necessarily the one that will
>     use it.

Suppose a port is built on the buildbot. The user is 'buildbot' and so
the value of $user_home will be something like '/Users/buildbot'. An end
user then installs the port on their system. The value of $user_home
will be different, for example '/Users/steve'. So if anything involving
the value of $user_home ended up in the binary archive, it is wrong on
the user's system.

- Josh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Bradley Giesbrecht-3
In reply to this post by Umesh Singla-2
> On Aug 4, 2017, at 1:46 PM, Umesh Singla <[hidden email]> wrote:
>
> On a side note, I didn't get this part:
>
> The user installing the port is not necessarily the one that will use it.

macOS is a multi-user system. The installed ports are largely available to any system user.


Brad

db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

db
In reply to this post by Joshua Root-8
On 4 Aug 2017, at 22:58, Joshua Root <[hidden email]> wrote:
> Suppose a port is built on the buildbot. The user is 'buildbot' and so the value of $user_home will be something like '/Users/buildbot'.

During testing I didn't thoroughly checked that env var there. I suppose, it could be deleted or set to nil and left to the user to set it himself. As I said, I wrote the port for me, and uploaded it for others to test, as I couldn't figure out a (better) way to set it in the startup item and didn't find documentation on how macports would handle this case.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Joshua Root-8
On 2017-8-5 07:14 , db wrote:
> On 4 Aug 2017, at 22:58, Joshua Root <[hidden email]> wrote:
>> Suppose a port is built on the buildbot. The user is 'buildbot' and so the value of $user_home will be something like '/Users/buildbot'.
>
> During testing I didn't thoroughly checked that env var there. I suppose, it could be deleted or set to nil and left to the user to set it himself. As I said, I wrote the port for me, and uploaded it for others to test, as I couldn't figure out a (better) way to set it in the startup item and didn't find documentation on how macports would handle this case.

I don't think there is a good way to do it if the user's home directory
must be encoded into the plist. But I suspect that is not the case, and
Rainer has mentioned a good alternative in the ticket.

- Josh
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

db
On 5 Aug 2017, at 10:00, Joshua Root <[hidden email]> wrote:
> I don't think there is a good way to do it if the user's home directory must be encoded into the plist. But I suspect that is not the case, and Rainer has mentioned a good alternative in the ticket.

IPFS_PATH sets the path to ipfs' repo for filesystem, web hosting, p2p, cdn, whatever you use it for, and defaults to ~/.ipfs. Since after writing the portfile I realised that the datastore needs to be initialised before loading the daemon anyway, I rather recreate the startup item without the env var and put a note for the user to set it, if need be.

This should be fine (haven't tried yet)

startupitem.create      yes
startupitem.executable  ${prefix}/bin/${name} daemon

I assume it adds

        <key>Disabled</key>
        <true/>
        <key>KeepAlive</key>
        <true/>

but not

        <key>RunAtLoad</key>
        <true/>

I checked the Daemons and Services Programming Guide, but couldn't find any info on RunAtLoad. It's not clear to me that KeepAlive implies starting after boot.


Go is not required at runtime, I missed that and will put it in depends_build.


Re autocompletion file, is it advised, as suggested in the ticket, to copy it to ${prefix}/share/bash-completion/completions/ipfs instead of another directory like bash_completion.d? I don't know if bash-completion would automatically source such file and if it's not installed it should be sourced from rc anyway. I could use a block like docker-machine's port, although I don't quite grasp what depends_run-append exactly does there.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Umesh Singla-2
In reply to this post by Joshua Root-8
That cleared it up. Thanks.

On Sat, Aug 5, 2017 at 2:28 AM, Joshua Root <[hidden email]> wrote:
On 2017-8-5 06:46 , Umesh Singla wrote:
On a side note, I didn't get this part:

    The user installing the port is not necessarily the one that will
    use it.

Suppose a port is built on the buildbot. The user is 'buildbot' and so the value of $user_home will be something like '/Users/buildbot'. An end user then installs the port on their system. The value of $user_home will be different, for example '/Users/steve'. So if anything involving the value of $user_home ended up in the binary archive, it is wrong on the user's system.

- Josh

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Bradley Giesbrecht-3
In reply to this post by db
> On Aug 5, 2017, at 3:55 AM, db <[hidden email]> wrote:
>> docker-machine's port, although I don't quite grasp what depends_run-append exactly does there.

Depends_run-appends adds to the depends_run variable.

man portfile /variable-append


Regards,
Bradley Giesbrecht (pixilla)
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

db
On 7 Aug 2017, at 20:03, Bradley Giesbrecht <[hidden email]> wrote:
>> On Aug 5, 2017, at 3:55 AM, db <[hidden email]> wrote:
>>> docker-machine's port, although I don't quite grasp what depends_run-append exactly does there.
> Depends_run-appends adds to the depends_run variable.

That I knew so far, but docker-machine uses a path dependency in prefix for bash-completion.

depends_run-append path:etc/bash_completion:bash-completion

Does it mean that it checks if that shell script exists in order to run? What if it doesn't?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Joshua Root-8
On 2017-8-8 04:43 , db wrote:

> On 7 Aug 2017, at 20:03, Bradley Giesbrecht <[hidden email]> wrote:
>>> On Aug 5, 2017, at 3:55 AM, db <[hidden email]> wrote:
>>>> docker-machine's port, although I don't quite grasp what depends_run-append exactly does there.
>> Depends_run-appends adds to the depends_run variable.
>
> That I knew so far, but docker-machine uses a path dependency in prefix for bash-completion.
>
> depends_run-append path:etc/bash_completion:bash-completion
>
> Does it mean that it checks if that shell script exists in order to run? What if it doesn't?

Dependency specifications are documented here:
<https://guide.macports.org/chunked/reference.dependencies.html#reference.dependencies.types>

- Josh
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

db
On 7 Aug 2017, at 23:03, Joshua Root <[hidden email]> wrote:
> Dependency specifications are documented here: <https://guide.macports.org/chunked/reference.dependencies.html#reference.dependencies.types>

I already read that too, but don't see why in case of docker-machine a path dependency makes more sense than a port one.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Joshua Root-8
On 2017-8-8 07:55 , db wrote:
> On 7 Aug 2017, at 23:03, Joshua Root <[hidden email]> wrote:
>> Dependency specifications are documented here: <https://guide.macports.org/chunked/reference.dependencies.html#reference.dependencies.types>
>
> I already read that too, but don't see why in case of docker-machine a path dependency makes more sense than a port one.

Because of bash-completion-devel.

- Josh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

Ryan Schmidt-24

On Aug 7, 2017, at 17:01, Joshua Root wrote:
> On 2017-8-8 07:55 , db wrote:
>> On 7 Aug 2017, at 23:03, Joshua Root wrote:
>>> Dependency specifications are documented here: <https://guide.macports.org/chunked/reference.dependencies.html#reference.dependencies.types>
>> I already read that too, but don't see why in case of docker-machine a path dependency makes more sense than a port one.
>
> Because of bash-completion-devel.

path:-style dependencies are used when more than one port could satisfy the dependency, in this case the development and stable versions of bash-completion.

db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: get user's home

db
On 8 Aug 2017, at 02:12, Ryan Schmidt <[hidden email]> wrote:
> path:-style dependencies are used when more than one port could satisfy the dependency, in this case the development and stable versions of bash-completion.


Thanks, that cleared it up.

Re ipfs, I left the startup item for the user to install (as I don't see a use of startup item for launch agents), corrected the go dependency and left the autocompletion as it was (never got feedback on copying to ${prefix}/share/bash-completion/).
Loading...