Re: help with ln linking Please! [attn manpage authors!]
Gary W. Swearingen [EMAIL PROTECTED] wrote: ln [-fhinsv] linked_filename [link_filename] ln [-fhinsv] linked_filename ... dir_filename link existing_filename alternate_filename This is cleaner, but I think filename should be standard in filenames. But it is not a filename. True. /etc/malloc.conf is a nice example of cases that this holds true, and the 'source' doesn't have to be a real file, or exist at all for that matter. Yuck; malloc.conf is nasty. No, it's extremely useful and efficient. There should be more software using symlinks like that. (BTW, Netscape does it for its lockfile, too, even though efficiency isn't much of an issue in that case.) Also, symlinks are an easy way to atomically check and create lockfiles in shell scripts. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
(10.09.2002 @ 0209 PST): Oliver Fromme said, in 1.2K: Gary W. Swearingen [EMAIL PROTECTED] wrote: ln [-fhinsv] linked_filename [link_filename] ln [-fhinsv] linked_filename ... dir_filename link existing_filename alternate_filename linked should be avoided. this is the exact problem the current documentation has. linked from? linked too? i'd explain it like this: i'd give the synopsis, then an immediate example. i'd LOVE to see a quick sample USEFUL and most common invocation of a short command right there in the synopsis section. i think many such utilities' manpages should do that. ln [-b0rk] link_to [link_from] % ln file link makes a link FROM link TO file. -Adam -- Oh good, my dog found the chainsaw. -Lilo, Lilo Stitch Adam Weinberger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
Oliver Fromme [EMAIL PROTECTED] writes: Gary W. Swearingen [EMAIL PROTECTED] wrote: ln [-fhinsv] linked_filename [link_filename] ln [-fhinsv] linked_filename ... dir_filename link existing_filename alternate_filename This is cleaner, but I think filename should be standard in filenames. But it is not a filename. It's a string which is used by ln(1) and the kernel's directory software for a filename; if people want to misuse it for storing PIDs or control strings or MP3s, that's an abuse of the system which the manual shouldn't bother to accommodate. Yuck; malloc.conf is nasty. No, it's extremely useful and efficient. ... Also, symlinks are an easy way to atomically check and create lockfiles in shell scripts. Useful, efficient, easy -- and yucky, nasty, kludgy. Apt to break if the directory scheme changes or to prevent improvements to same. Maybe it should be: ln string_for_directory filename_to_access_string_by Just kidding. It can't end in a preposition. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
Gary W. Swearingen [EMAIL PROTECTED] wrote: Oliver Fromme [EMAIL PROTECTED] writes: Gary W. Swearingen [EMAIL PROTECTED] wrote: ln [-fhinsv] linked_filename [link_filename] ln [-fhinsv] linked_filename ... dir_filename link existing_filename alternate_filename This is cleaner, but I think filename should be standard in filenames. But it is not a filename. It's a string which is used by ln(1) and the kernel's directory software for a filename; if people want to misuse it for storing PIDs or control strings or MP3s, that's an abuse of the system which the manual shouldn't bother to accommodate. No, it is not an abuse. It is utilizing standard UNIX behaviour, for very good reason. (I have to admit that I wouldn't want to store an MPEG file in the string of a symbolic link, though, and I can't imagine a good reason why someone would want to do that. Apart from that, the length of symbolic links is limited by SYMLINK_MAX, which is 1023 bytes.) Yuck; malloc.conf is nasty. No, it's extremely useful and efficient. ... Also, symlinks are an easy way to atomically check and create lockfiles in shell scripts. Useful, efficient, easy -- and yucky, nasty, kludgy. Apt to break if the directory scheme changes or to prevent improvements to same. I don't know what you mean by if the directory scheme changes. The behaviour of symbolic links is well-defined, exists for ages, and is fundamental to UNIX filesystems. Let me quote from the SUSv3 / IEEE Std 1003.1-2001 (POSIX) specification of the symlink() systemcall, which should be regarded as authoritative: | int symlink(const char *path1, const char *path2); | | The symlink() function shall create a symbolic link | called path2 that contains the string pointed to by | path1 (path2 is the name of the symbolic link | created, path1 is the string contained in the symbolic | link). | | The string pointed to by path1 shall be treated only | as a character string and shall not be validated as a | pathname. | [...] | | The presence of a hard link guarantees the existence of | a file, even after the original name has been removed. | A symbolic link provides no such assurance; in fact, the | file named by the path1 argument need not exist when | the link is created. I think that's as clear as it can be. Maybe the problem with the ln(1) manpage stems from the historical mistake to support hard links and symbolic links with the same utility (ln), even though they are really fundamentally different concepts. It's two separate system calls (link(2) for hard links, symlink(2) for symblic links). It should really be two different utilities (or at least two different hard links to the same utility), with two different manual pages. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
On 8 Oct 2002, Gary W. Swearingen wrote: PL The manpage is super unclear about sourcefile and targetfile, I have PL said this for years. Think of this paragraph: [snip] PL ... as this instead `ln -s actualfile linkfile` That's not the best way to think of it, since actualfile need not be an actual file! Nor existing, as the manual has. The source Nor existing? How so? [!] concept is actually pretty good, since the source file is used as the source of data when target file is accessed. Confusion comes about mostly because the ls command shows an arrow pointing from the target (AKA destination) to the source, backwards from what most people would expect when thinking of source and destination/target. The arrow points away from the target! It also shows them in reverse order from how they are given to ln. That's a good point, the arrows do point in the wrong direction. :) How about this: ln [-fhinsv] source_filename [link_filename] I just TRY to remember them as being bassackwards from the more natural order of ls: link - source LOL - on a second read of your commentary I noticed 'bassackwards.' Anybody else have terms they'd prefer the manual use in both the SYNOPSIS and DESCRIPTION? I like Adam's ideology about the file you want to create comes last. Like an old man on medication with an ejaculatory condition. Har har. Peter, who have you said this for years TO? Have you filed a Problem Report which I could send a patch for? If so, what's the number? The said this for years was probably me cursing and drooling asleep. -- Peter Leftwich President Founder Video2Video Services Box 13692, La Jolla, CA, 92039 USA +1-413-403-9555 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
(10.07.2002 @ 2216 PST): Peter Leftwich said, in 1.5K: On Mon, 7 Oct 2002, SweeTLeaF wrote: I am in the /usr/root dir ln -s desktop /root/Desktop/tmp You should be using `ln -s /root/Desktop/tmp /usr/root/desktop` no, he shouldn't be. when he looks at /root/Desktop/tmp he wants to see the contents of /usr/root/desktop. remember it this way, peter: the file that doesn't exist yet comes last. the problem with your command, sweetleaf, is that ln -s desktop ... doesn't make a link to desktop in your current directory. it makes it relative to the link. your command makes a link from /root/Desktop/tmp to /root/Desktop/desktop. unless you have a specific reason for making links relative, qualifying all links with full path names is your safest bet. -Adam -- Oh good, my dog found the chainsaw. -Lilo, Lilo Stitch Adam Weinberger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
Peter Leftwich [EMAIL PROTECTED] writes: The manpage is super unclear about sourcefile and targetfile, I have said this for years. Think of this paragraph: SYNOPSIS ln [-fhinsv] source_file [target_file] ... ... as this instead `ln -s actualfile linkfile` That's not the best way to think of it, since actualfile need not be an actual file! Nor existing, as the manual has. The source concept is actually pretty good, since the source file is used as the source of data when target file is accessed. Confusion comes about mostly because the ls command shows an arrow pointing from the target (AKA destination) to the source, backwards from what most people would expect when thinking of source and destination/target. The arrow points away from the target! It also shows them in reverse order from how they are given to ln. How about this: ln [-fhinsv] source_filename [link_filename] I just TRY to remember them as being bassackwards from the more natural order of ls: link - source Anybody else have terms they'd prefer the manual use in both the SYNOPSIS and DESCRIPTION? Peter, who have you said this for years TO? Have you filed a Problem Report which I could send a patch for? If so, what's the number? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
(10.08.2002 @ 1151 PST): Gary W. Swearingen said, in 1.4K: How about this: ln [-fhinsv] source_filename [link_filename] I just TRY to remember them as being bassackwards from the more natural order of ls: link - source i still stand by my method: the file you want the command to create comes last. Anybody else have terms they'd prefer the manual use in both the SYNOPSIS and DESCRIPTION? how about ln [-fhinsv] link_to [link_from] -Adam -- Oh good, my dog found the chainsaw. -Lilo, Lilo Stitch Adam Weinberger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
Gary W. Swearingen [EMAIL PROTECTED] wrote: How about this: ln [-fhinsv] source_filename [link_filename] FWIW, the source doesn't have to be a file at all, in the case of symbolic links. I think the correct term is link target in that case -- that's how it is called in the standards (POSIX, SUSvX etc.). Maybe the manpage should differentiate those two cases, like this: ln [-fhinv] existing_filename [another_filename] ln -s [-fhinv] symlink_target [symlink_name] That would be completely clear, IMO. Although maybe a bit too verbose. Personally, I memorize it like this: The order of arguments to ln is the same as that of mv or cp -- the existing file comes first (OK, in the case of symlinks it doesn't really have to exist), and the new thing comes last. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
(10.08.2002 @ 1514 PST): Oliver Fromme said, in 1.2K: ln [-fhinv] existing_filename [another_filename] ln -s [-fhinv] symlink_target [symlink_name] That would be completely clear, IMO. Although maybe a bit too verbose. too verbose? i disagree. (OK, in the case of symlinks it doesn't really have to exist), and the new thing comes last. most people who would benefit from having ln spelled out for them probably won't be doing terribly difficult things with it ::) -Adam -- Oh good, my dog found the chainsaw. -Lilo, Lilo Stitch Adam Weinberger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
On 2002-10-09 00:14, Oliver Fromme [EMAIL PROTECTED] wrote: Gary W. Swearingen [EMAIL PROTECTED] wrote: How about this: ln [-fhinsv] source_filename [link_filename] FWIW, the source doesn't have to be a file at all, in the case of symbolic links. I think the correct term is link target in that case -- that's how it is called in the standards (POSIX, SUSvX etc.). True. /etc/malloc.conf is a nice example of cases that this holds true, and the 'source' doesn't have to be a real file, or exist at all for that matter. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: help with ln linking Please! [attn manpage authors!]
On Mon, 7 Oct 2002, SweeTLeaF wrote: I am in the /usr/root dir ln -s desktop /root/Desktop/tmp You should be using `ln -s /root/Desktop/tmp /usr/root/desktop` The manpage is super unclear about sourcefile and targetfile, I have said this for years. Think of this paragraph: SYNOPSIS ln [-fhinsv] source_file [target_file] Given one or two arguments, ln creates a link to an existing file source_file. If target_file is given, the link has that name; target_file may also be a directory in which to place the link; otherwise it is placed in the current directory. If only the directory is specified, the link will be made to the last component of source_file. ... as this instead `ln -s actualfile linkfile` Now i was exspecting to see all the contents for /usr/root/desktop when i viewed the /root/Desktop/tmp dir. but that did not happen. Now when i go to /root/Desktop/tmp ...i see the link for desktop but when i do a ls desktop to try and view the files inside desktop i get nothing and a cd desktop gives an sys link error...and there are more files in desktop. I guess i am trying to mirror the two dir, so even though they have different names and on different filesystems, i will see the same contents. Thanks for any help. I think you just had it backwards. -- Peter Leftwich President Founder Video2Video Services Box 13692, La Jolla, CA, 92039 USA +1-413-403-9555 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
