On Sun, Sep 14, 2014 at 6:09 PM, Brandon Allbery
wrote:
> On Sun, Sep 14, 2014 at 6:07 PM, Bill Bogstad wrote:
>
>> I think you are thinking of /bin/ln which was how normal users were
>> supposed to make
>> links to files (with /bin/rm being the way to remove them)
>>
>
> Just to repeat what you
On Sun, Sep 14, 2014 at 6:07 PM, Bill Bogstad wrote:
> I think you are thinking of /bin/ln which was how normal users were
> supposed to make
> links to files (with /bin/rm being the way to remove them)
>
Just to repeat what you claim to be replying to: "ln was, even then, a bit
too "user friend
On Sun, Sep 14, 2014 at 11:45 PM, Brandon Allbery
wrote:
> On Sun, Sep 14, 2014 at 5:36 PM, Bill Bogstad wrote:
>
>> /etc/*link was just a slightly safer way to accomplish this and in my
>> opinion was intended to fix filesystem corruption not as a supported
>> interface for general use.
>
>
> I
On Sun, Sep 14, 2014 at 5:51 PM, Alexander Lobodzinski <
lobo+lo...@dzinski.net> wrote:
> However I'm curious how it's implemented - as on other Unices, link(2)
> fails with EPERM if "the file named by path1 is a directory".
>
Actually, link(2) is happy to do it; but the manpage is from FreeBSD,
> And in a similar vein, HFS+ allows hard links to directories, which is a
> good way to confuse your filesystem on must Unixes (and therefore prevented
> by the OS). OS X also allows use of this feature(?), but may restrict it in
> recent versions.
Yep, Time Machine on OS X uses hard linked direc
On Sun, Sep 14, 2014 at 5:36 PM, Bill Bogstad wrote:
> /etc/*link was just a slightly safer way to accomplish this and in my
> opinion was intended to fix filesystem corruption not as a supported
> interface for general use.
It *did* have a general use, though: ln was, even then, a bit too "use
On Sun, Sep 14, 2014 at 5:09 PM, Brandon Allbery
wrote:
> On Sun, Sep 14, 2014 at 11:02 AM, Edward Ned Harvey (lopser) <
> lop...@nedharvey.com> wrote:
>
>> > From: Edward Ned Harvey (lopser)
>> So the only point in question is whether or not "." and ".." are
>> permitted filenames in extfs. I t
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org]
> On Behalf Of Tom Limoncelli
>
> ...which leads to this Unix trivial question: What's the one byte
> value that can not appear in a Unix (POSIX) filename? \0 (i.e. ASCII
> 0)
But I'm running OSX. ;-) All unicode cha
On Sun, Sep 14, 2014 at 11:16 AM, Tom Limoncelli wrote:
> In ext3/4 (and UFS and all previous Unix file systems)
Not quite all; older HP/UX didn't even have them, the tree structure was
maintained outside of the visible directory data. I think HFS+ does
something similar but maintains compatibi
On Sun, Sep 14, 2014 at 11:02 AM, Edward Ned Harvey (lopser)
wrote:
> So the only point in question is whether or not "." and ".." are permitted
> filenames in extfs. I think we all know the answer to this question. They
> are reserved, so if we want to get semantic, we could say they are
> t
On Sun, Sep 14, 2014 at 11:09 AM, Brandon Allbery
wrote:
> If you can find an OS API that supports it, there's nothing preventing
> their use. For that matter, I once worked with a System III that would
> happily allow root to replace . and ..
And in a similar vein, HFS+ allows hard links to di
On Sun, Sep 14, 2014 at 11:02 AM, Edward Ned Harvey (lopser) <
lop...@nedharvey.com> wrote:
> > From: Edward Ned Harvey (lopser)
> So the only point in question is whether or not "." and ".." are permitted
> filenames in extfs. I think we all know the answer to this question. They
> are reserved
> From: Edward Ned Harvey (lopser)
>
> But I'm running OSX. ;-) All unicode characters are allowed, including
> NUL.
> (Although many applications will impose their own restrictions.)
As mentioned, this belief was based I thought on several sources, but
apparently it distills down to a sing
> From: Tom Limoncelli [mailto:t...@whatexit.org]
>
> "could be pure bunk" -- So far I haven't found evidence of anything in
> your earlier email as being true.
Yikes. Ok, I'll go back and respond to my own email then.
___
Tech mailing list
Tech@lists.
On Sun, Sep 14, 2014 at 10:25 AM, Edward Ned Harvey (lopser) <
lop...@nedharvey.com> wrote:
> Wikipedia http://en.wikipedia.org/wiki/HFS_Plus
> Allowed characters in filenames Unicode, any character, including NUL. OS
> APIs may limit some characters for legacy reasons
>
All this asserts is that
"could be pure bunk" -- So far I haven't found evidence of anything in
your earlier email as being true.
The only assertions from your previous email we haven't examined were
(1) that you use OSX, (2) btrfs disallows filenames "." and "..".
As far as (2) is concerned, I haven't used btrfs, but I
> From: Tom Limoncelli [mailto:t...@whatexit.org]
>
> Could you write a program that creates a file with either of those
> chars? I'd really like to see this.
Oh, no. Not me. As I said, many applications will impose their own
restrictions, and that includes perl and mono and bash, and I thin
On Sun, Sep 14, 2014 at 9:58 AM, Tom Limoncelli wrote:
> Trying to create a file with \0 in it:
It would not surprise me to find that the Aqua API allows \0 to be encoded
using one of the UTF8 extensions (e.g. C0 80). That said, POSIX does not
specify any Unicode encoding, but bytes, and any en
On Sun, Sep 14, 2014 at 9:32 AM, Edward Ned Harvey (lopser)
wrote:
> But I'm running OSX. ;-) All unicode characters are allowed, including
> NUL. (Although many applications will impose their own restrictions.)
>
> And in btrfs, '/' is disallowed (in addition to \0). And in extfs, \0, '/'
On Sat, Sep 13, 2014 at 9:14 PM, Robert Hajime Lanning
wrote:
> I always use "-print0" and "-0". It has become habitual. Of course it
> screws me up, when I am not on a GNU based system. Which, thankfully, has
> become more and more rare. :)
...which leads to this Unix trivial question: What's
On 09/13/14 16:05, Allan West wrote:
On 9/13/14 3:11 PM, Robert Hajime Lanning wrote:
I have run into issues with "-print" and "xargs"... spaces in filenames...
Doesn't happen much when dealing with source code (.c .cs .h), but it happens
a lot when dealing with music and documents from Windows/
On 9/13/14 3:11 PM, Robert Hajime Lanning wrote:
> On 09/13/14 11:51, Doug Hughes wrote:
>> FWIW: this is a perfect use case for xargs instead of exec. You'll save
>> a lot of fork/clone system calls and simplify your find. Brandon pointed
>> out the main problem, but consider this alternative:
>
On Sep 13, 2014, at 2:51 PM, Doug Hughes wrote:
> FWIW: this is a perfect use case for xargs instead of exec.
Or, something like ack (http://beyondgrep.com) and its scions (e.g.
https://github.com/ggreer/the_silver_searcher).
-- dNb
___
Tech m
Robert Hajime Lanning writes:
> On 09/13/14 11:51, Doug Hughes wrote:
> > FWIW: this is a perfect use case for xargs instead of exec. You'll save
> > a lot of fork/clone system calls and simplify your find. Brandon pointed
> > out the main problem, but consider this alternative:
> >
> > fi
On 09/13/14 11:51, Doug Hughes wrote:
> FWIW: this is a perfect use case for xargs instead of exec. You'll save
> a lot of fork/clone system calls and simplify your find. Brandon pointed
> out the main problem, but consider this alternative:
>
> find . -name '*.cs' -print -o -name '*.c' -print -
On 9/13/2014 8:25 AM, Edward Ned Harvey (lopser) wrote:
Can anybody explain this behavior to me?
I'm searching for files that contain the string "LockFile" in them. I
know of one place where it exists already... But the following command
only returns one result, which is not the result I alrea
On Sat, Sep 13, 2014 at 12:25:28PM +, Edward Ned Harvey (lopser) wrote:
> Can anybody explain this behavior to me?
>
> I'm searching for files that contain the string "LockFile" in them. I know
> of one place where it exists already... But the following command only
> returns one result, w
> From: Brandon Allbery [mailto:allber...@gmail.com]
>
> Nope; bug in your brain. As soon as you start using -o / -or, you need to deal
> with precedence.
>
> find . \( -name '*.[ch]' -o -name '*.cs' \) -print
Bahhh! Thank you. That was very non-intuitive. In fact, either using
parenthes
On Sat, Sep 13, 2014 at 8:45 AM, Edward Ned Harvey (lopser) <
lop...@nedharvey.com> wrote:
> Actually, I got it: For some reason, the find command itself finds
> "file-io.c" in its results, but when I do "-exec" then it only results in
> '*.h' files printing out. I'm reasonably certain that's a
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org]
> On Behalf Of Edward Ned Harvey (lopser)
>
> I'm searching for files that contain the string "LockFile" in them. I know of
> one place where it exists already... But the following command only returns
> one result, which
Can anybody explain this behavior to me?
I'm searching for files that contain the string "LockFile" in them. I know of
one place where it exists already... But the following command only returns
one result, which is not the result I already knew existed.
Edwards-MacBook-Pro:mono eharvey$ find
31 matches
Mail list logo
