On Thursday 20 September 2007, Mike Frysinger wrote:
> no, this cannot live in baselayout (the package that creates /root/), because
> it cannot be run everytime a user upgrades the baselayout package. no, it
> cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to
> make st
Roy Marples wrote:
> No it's not. bash does not recommend anything of the sort. It just
> states what files are optionally used during initialisation.
>
> What I'm driving at is that you're making claims that things are broken
> or recommended when in fact they are not. Try reading some RFC's and
>
Roy Marples wrote:
> Looking over the bash man page, I cannot see the word recommended
> anywhere near .bash_profile. Could you clarify where you think bash
> recommends this?
>
> Thanks
>
> Roy
>
Why, sure. It's my interpretation, but a reasonable one, I think. It
recommends it in its imple
Renat Golubchyk wrote:
> That's wrong. Quote:
>
> "When bash is invoked as an interactive login shell, or as a non-inter-
> active shell with the --login option, it first reads and executes com-
> mands from the file /etc/profile, if that file exists. After reading
> that file, it looks for ~/
Andrew. Sorry 'bout the top posting; won't do it again. For the rest,
please see my reply to Mike Auty on the same topic.
- John
--
[EMAIL PROTECTED] mailing list
Mike, I agree. But, the file that _must_ exist isn't "~/.bashrc" but
"~/.bash_profile". That's where the that particular bit of
man-page-defined behavior is implemented. If "~/.bash_profile" doesn't
exist, then "~/.bashrc" won't be sourced whether it exists or not.
- John
--
[EMAIL PROTECTED]
not a login shell is started, bash reads and
executes commands from ~/.bashrc, if that file exists." Is that really
the intention here? To break upstream-defined behavior?
- John
Alin Năstac wrote:
> John R. Graham wrote:
>
>> Why can't the simple little default
&
Mike, that exploit is neither easier nor harder if a default
.bash_profile exists. Or, am I missing something?
- John
Mike Doty wrote:
> John R. Graham wrote:
>> like sys-apps/miscfiles. But where it should or shouldn't come from
>> doesn't answer the fundamental q
Andrew Gaffney wrote:
> When catalyst builds a stage tarball, it doesn't add any additional
> files. All files in any stage tarball are created by one of the
> packages contained within. In order to do this, a package such as
> baselayout would have to install the file.
>
> Looking at my local in
On the forums, I've seen the question, "Why isn't my .bashrc being
executed when I log in as root but is being executed when I log in as a
normal user?," asked half a dozen times on the forums. Heck, I even
asked it myself a few years ago. Now, two years later, from a slightly
more mature level of
On 6/15/07, Vlastimil Babka <[EMAIL PROTECTED]> wrote:
Syntax shouldn't repeat package name twice. It wouldn't make much sense
to use it with >=some-cat/foo-4.0
I was thinking about AND dependencies but the only reasonable examples I
could thing of were ranges of versions and thus didn't recogn
Marijn Schouten (hkBst) wrote:
> AND is already the implicit combinator. Thus simply listing both these
> atoms
> gives what you want:
>
> > =some-cat/foo-4.0
>
> Still a special syntax for ranges seems like a good idea. If only portage
> would not upgrade past such specifications (and downgrade t
I occasionally run across a package version dependency issue that cannot
be elegantly solved by the current dependency syntax. Every time I've
come across this, it's boiled down to a range. For example, package
some-cat/foo has the following versions in the tree
some-cat/foo-4.0.0-r2
som
13 matches
Mail list logo
