| Summary: | (NEW PORT) osg - Open Scene Graph | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | aa8vb <aa8vb> | ||||
| Component: | Individual Port(s) | Assignee: | freebsd-ports (Nobody) <ports> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | aa8vb | ||||
| Priority: | Normal | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
aa8vb
2001-04-28 20:20:01 UTC
State Changed From-To: open->analyzed This PR is missing pkg-plist. On Sun, May 20, 2001 at 08:42:43AM -0400, Randall Hopper wrote: > I pulled out my old message and it does have the pkg-plist in it. The > fault lies in FreeBSD's shar which apparently does not work except for text > files where the very last character is an EOL. It creates a shell archive > that FreeBSD's /bin/sh does not see the END-of-... marker for the file and > keeps tacking text from the next file into the previous. Ah, sorry, should have looked again. > FreeBSD's shar needs a fix, or at least a CAVEAT listed in the man page. No, I don't think there is a "fix", because if you add formatting to a file where there wasn't one before, it won't be the same as it used to be (and this CAN be important in terms of last EOL). It's a fundamental problem with the shar formatting. Regardless, I've always wondered how people end up with files that don't have an EOL on the last line... never happened to me. BTW, it's not the very last character that must be an EOL (this would be an EOF), just the last character on the last line before the EOF. > Here is a .tgz of the exact same set of files I submitted in my PR (so you > can try shar if you'd like). Sorry this didn't work the first time. From > now on, I'll submit MIME-attached .tgz files rather than the shar things > recommended in the porters handbook. I know they work. shar's actually do work. I never had trouble with them: > <1 5027-0> (7:45:33) [will@puck ~]% mkdir test > <1 5028-0> (7:45:35) [will@puck ~]% cat > test/blah > this is a test > just a test > <1 5029-0> (7:45:43) [will@puck ~]% cat > test/blah2 > another test > this file has an EOL > <1 5030-0> (7:45:50) [will@puck ~]% ls -l test > total 2 > -rw-rw-r-- 1 will will 27 May 20 07:45 blah > -rw-rw-r-- 1 will will 34 May 20 07:45 blah2 > <1 5031-0> (7:46:01) [will@puck ~]% cat test/blah;echo "--";cat test/blah2 > this is a test > just a test > -- > another test > this file has an EOL > <1 5032-0> (7:46:14) [will@puck ~]% shar `find test` > test.shar > <1 5033-0> (7:46:24) [will@puck ~]% cat test.shar > # This is a shell archive. Save it in a file, remove anything before > # this line, and then unpack it by entering "sh file". Note, it may > # create directories; files and directories will be owned by you and > # have default permissions. > # > # This archive contains: > # > # test > # test/blah > # test/blah2 > # > echo c - test > mkdir -p test > /dev/null 2>&1 > echo x - test/blah > sed 's/^X//' >test/blah << 'END-of-test/blah' > Xthis is a test > Xjust a test > END-of-test/blah > echo x - test/blah2 > sed 's/^X//' >test/blah2 << 'END-of-test/blah2' > Xanother test > Xthis file has an EOL > END-of-test/blah2 > exit > > <1 5034-0> (7:46:26) [will@puck ~]% uuencoded tarballs also work, but they are less convenient except in large cases (which are fairly rare in ports), mainly because it's easier to examine how much work would be involved in getting a port in the tree when you can see the actual content in the raw text of the PR. -- wca Will Andrews: |I've always wondered how people end up with files that don't have an EOL |on the last line... never happened to me. It's an editor-related thing. Emacs for example has no problem creating files that don't end with EOL (I edit binary files in Emacs on occasion because it doesn't insert characters that I don't tell it to). vi on the other hand seems to prefer adding EOL at EOF. Randall -- Randall Hopper aa8vb@nc.rr.com On Sun, May 20, 2001 at 09:20:10AM -0400, Randall Hopper wrote:
> It's an editor-related thing. Emacs for example has no problem creating
> files that don't end with EOL (I edit binary files in Emacs on occasion
> because it doesn't insert characters that I don't tell it to). vi on the
> other hand seems to prefer adding EOL at EOF.
I've used both vi & vim, and never had problems with either in this
aspect. But then again, I don't edit binary files...
--
wca
State Changed From-To: analyzed->closed Port was added with many corrections and improvements. Please study those and try to improve your skills in the future. Big thanks anyway! |