 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Perl / March 2005could not build a module
Hi, I am new to perl on Max OS X.I used to use perl on Windows. I just got a new Dual G5 last week. I just tried to install the RTF::TEXT::Converter module using the following command: perl -MCPAN -e 'install RTF::TEXT::Converter' I got the following error, the file perl.h is not there. The only file in the directory is libperl.dylib. What can I do? I don't want to do "please build and install your perl from a fresh perl distribution." if possible. ted zeng ====== error message CPAN.pm: Going to build P/PV/PVERD/RTF-Parser-1.07.tar.gz Error: Unable to locate installed Perl libraries or Perl source code. It is recommended that you install perl in a standard location before building extensions. Some precompiled versions of perl do not contain these header files, so you cannot build extensions. In such a case, please build and install your perl from a fresh perl distribution. It usually solves this kind of problem. (You get this message, because MakeMaker could not find "/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE/perl.h") Running make test Make had some problems, maybe interrupted? Won't test Running make install Make had some problems, maybe interrupted? Won't install > Error: Unable to locate installed Perl libraries or Perl source code. Install Xcode. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org > >Error: Unable to locate installed Perl libraries or Perl source code. > > Install Xcode. Perhaps I'm mistaken, but wouldn't it be more accurate to say "install the OS X development tools", rather than Xcode, per se? dha  SignatureDavid H. Adler - <dha@panix.com> - http://www.panix.com/~dha/ Hang on, you're a veggie, and you don't drink Guinness... why do I bother fancying you again??? - Alex Page > Perhaps I'm mistaken, but wouldn't it be more accurate to say "install > the OS X development tools", rather than Xcode, per se? As of OSX 10.3, "Xcode" is the name for the whole suite, in addition to the specific XCode IDE. Maybe it was decided that the 10.0 - 10.2 era "[Month] [Year] OSX Develeoper's Tools" was a clumsy name that had to be retired, and that having the same name for two things was acceptably annoying. *shrug* SignatureChris Devers > > Perhaps I'm mistaken, but wouldn't it be more accurate to say "install > > the OS X development tools", rather than Xcode, per se? > > As of OSX 10.3, "Xcode" is the name for the whole suite, in addition to > the specific XCode IDE. I missed that memo. Thanks for the clarification. Carry on. :-) dha SignatureDavid H. Adler - <dha@panix.com> - http://www.panix.com/~dha/ Oh, the irony. - Abigail Thanks. I will install the Xcode and see how it goes. ted > -----Original Message----- > From: Sherm Pendley [mailto:sherm@dot-app.org] [quoted text clipped - 11 lines] > Cocoa programming in Perl: http://camelbones.sourceforge.net > Hire me! My resume: http://www.dot-app.org > I will install the Xcode and see how it goes. You know where to find it? Quoting Joel Rees <joel_rees@sannet.ne.jp>: > > I will install the Xcode and see how it goes. > > You know where to find it? You need to become an "Apple Developer connection" Member thet ypu can dowload a lot of development tools. The Apple web site for the ADC is https://connect.apple.com Mario Mango Furnari SignatureIstituto di Cibernetica Eduardo Caianiello Comprensorio Olivetti, Building 70 Via Campi Flegrei, 34 80078 Pozzuoli Italy Tel: +39.0818675154 Fax: +39.0818675326 email:mf@cib.na.cnr.it ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ >>> I will install the Xcode and see how it goes. >> [quoted text clipped - 6 lines] > > https://connect.apple.com And if you don't have broadband, you can almost always find it somewhere in the OS install. Of course, it may not be the absolute latest, but it will be there. I was just wondering if Ted knew. Joel, Thanks. I did find it and install Xcode. I managed to install module "RTF::Text::Converter". But it doesn't work on Eggplant's script files. I even Opened the script file in Windows XP's Word and then Saved it. It still hangs. ( I used the example script Tests.pl that comes with the module.) Anyone has a good suggestion on a good RTF to Text converter That works well on Mac? Ted > -----Original Message----- > From: Joel Rees [mailto:joel_rees@sannet.ne.jp] [quoted text clipped - 5 lines] > > You know where to find it? > Anyone has a good suggestion on a good RTF to Text converter > That works well on Mac? Have you tried TextEdit? It comes with the OS, so it doesn't cost anything to give it a shot. Or, were you looking for a batch processing thing, to convert a bunch of files? sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org I need to do batch processing. In fact, I need to grap the text content of each file and process it using Perl. I just did a search and found the link http://daringfireball.net/2003/04/rtf_to_plain_text_translator which tells me to use inside the FileMerge folder convertRichTextToAscii to do the conversion. It works. I will need to hook it up with perl to do my job. ted >> Anyone has a good suggestion on a good RTF to Text converter >> That works well on Mac? [quoted text clipped - 6 lines] > > sherm-- > I need to do batch processing. In fact, I need to grap the text > content of each file > and process it using Perl. I figured "rtf2txt" would be a fairly obvious name, so on a hunch I googled for it. Turns out to be a good hunch. :-) <http://www.bluem.net/downloads/rtf2txt_en/> sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org Hi, Thanks for the help here. I am almost finishing my first tool on OS X. I am using TextEdit as the editor. I sometime use Pico, but I am still not comfortable with Unix editor. I know there must be some good editors for Perl. Do you have any recommendation? ted zeng Adobe Systems If you want to stay with something free, I'd suggest TextWrangler from Bare Bones: http://www.barebones.com/products/textwrangler/index.shtml It has good syntax coloring, and integrates well with the command-line perl - you can set a keyboard shortcut to run scripts & check their syntax, and you can write filters and other scripts in perl. Pretty sweet for a free product. Ian > Hi, > Thanks for the help here. I am almost finishing my first tool on OS X. [quoted text clipped - 5 lines] > ted zeng > Adobe Systems It also has a stationary feature, which enables you to create templates for various Perl files you may create. I have one for object oriented package files, and one for regular Perl scripts - both complete with POD stuff. Very nice. Cheers, John > From: Ian Ragsdale <ian@SKYLIST.net> > Date: Wed, 02 Mar 2005 11:50:01 -0600 [quoted text clipped - 22 lines] >> ted zeng >> Adobe Systems >>>>> "Ian" == Ian Ragsdale <ian@SKYLIST.net> writes: Ian> If you want to stay with something free, I'd suggest TextWrangler from Ian> Bare Bones: Ian> http://www.barebones.com/products/textwrangler/index.shtml Ian> It has good syntax coloring, and integrates well with the command-line Ian> perl - you can set a keyboard shortcut to run scripts & check their Ian> syntax, and you can write filters and other scripts in perl. Pretty Ian> sweet for a free product. Again, if you keep pushing "free", I'm going to say "emacs". :) Emacs has all that. And more. SignatureRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! >>>>>> "Ian" == Ian Ragsdale <ian@SKYLIST.net> writes: > [quoted text clipped - 14 lines] > Again, if you keep pushing "free", I'm going to say "emacs". :) > Emacs has all that. And more. "Keep" pushing free? I was the first response! :) I like vi better than emacs personally, but mainly cause I know it a lot better. For someone on OS X, that wishes to use a GUI (which was my assumption), would you really suggest they spend the time learning emacs or vi? My guess is that most people who suggest such things don't realize how long they spent learning how to be productive in it. I'd guess that anybody who learned vi or emacs after 2000 wouldn't suggest it. I personally learned it in '94 and still don't feel that productive in it. Ian >>>>> "Ian" == Ian Ragsdale <ian@SKYLIST.net> writes: Ian> "Keep" pushing free? Sorry, the collective "you". :) Ian> I'd guess that Ian> anybody who learned vi or emacs after 2000 wouldn't suggest it. I Ian> personally learned it in '94 and still don't feel that productive in Ian> it. What happens if I s/vi or emacs/perl/ to that sentence? Makes just about as much non-sense. I spend about half my day typing into an editor. If it wasn't for all the power of Emacs, I'd be lost by now. I suppose if you edit for only 15 minutes a day, you could afford to learn only as much as a GUI editor will let you do. :) SignatureRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! >I am using TextEdit as the editor. I sometime use Pico, but I am still >not comfortable with Unix editor. I know there must be some good >editors for Perl. Do you have any recommendation? BBEdit <http://www.barebones.com> and Affrus <http://www.latenightsw.com> spring to mind. Both cost money but are well worth it. Cheers, Regards, Phil. > Hi, > Thanks for the help here. I am almost finishing my first tool on OS X. [quoted text clipped - 5 lines] > ted zeng > Adobe Systems Vim. Steep learning curve, learn once, use forever, anywhere. http://danconia.org >> Hi, >> Thanks for the help here. I am almost finishing my first tool on OS X. > Vim. Steep learning curve, learn once, use forever, anywhere. > > http://danconia.org I'm a vim and BBEdit user. If you're interested in a collaborative environment, you can check out SubEthaEdit at http://www.codingmonkeys.de/subethaedit/ SignatureMike Schienle There is a double clickable version of emacs available. There is a link to it at Apple's sight. Mar 2, 2005 kl. 6:38 PM skrev Ted Zeng: > Hi, > Thanks for the help here. I am almost finishing my first tool on OS X. [quoted text clipped - 5 lines] > ted zeng > Adobe Systems "Home is not where you are born, but where your heart finds peace" - Tommy Nordgren, "The dying old crone" >There is a double clickable version of emacs available. There is a link >to it at Apple's sight. I'm thinking that if he's not comfortable with pico maybe emacs is not the best idea... Cheers, Regards, Phil. >I'm thinking that if he's not comfortable with pico maybe emacs is >not the best idea... I'd love to hear a convincing explanation from someone why anyone would use such tools in preference to TextWrangler, BBEdit or Affrus. I can imagine they'd make it a chore to write code in us-ascii and either a nightmare or an impossibility to deal with non-ascii, but maybe that's because I'm just an unreformed Mac user :-) JD >> I'm thinking that if he's not comfortable with pico maybe emacs is not >> the best idea... [quoted text clipped - 6 lines] > > JD They aren't free (well BBedit and Affrus), they aren't cross platform (why learn a different editor for each platform), and they require lots of clicky. I have never logged into a system where I couldn't use vi. (well maybe a windows box, but it didn't take long to install gvim or cygwin.) http://danconia.org >>> I'm thinking that if he's not comfortable with pico maybe emacs is >>> not the best idea... [quoted text clipped - 15 lines] > > http://danconia.org p.s. forgot one, they require some sort of "X" like display, have you ever edited a text file on a remote machine with no remote display? or a remote display over a modem? no thanks.... http://danconia.org I would urge all of you that have spoken so far to try out jEdit (http://jedit.org). > I would urge all of you that have spoken so far to try out jEdit > (http://jedit.org). What kind of geek would I be if I ignored an editor thread? ;) I also like jEdit, here are a few of the reasons: * Open-source (free as in speech) * Lots of nice plugins * Very customizable * Multi-platform (Java-based) * Active & responsive developers Out of the box many people are not wowed, but if you look under the hood, and really customized it to your needs, it can do a whole heck of a lot. Like many open-source apps, it may require an investment of time to get what you are after, but for me it was well worth it. Pete Mostly just because no one else mentioned it, I rather like to use Mahon's "ee" or "aee". Almost no learning curve but much superior to pico, IMHO. If you must use a GUI version, and can tolerate X-windows, there's even an "xee". I believe FreeBSD includes it as part of a nominal install. Rather wish that OS-X did too. SignatureWalter M. Pawley <walt@wump.org> Wump Research & Company 676 River Bend Road, Roseburg, OR 97470 541-672-8975 Tired of seeing runaway threads on this topic, I've created a page so that next time this is asked, only one reply is (hopefully) needed: Look at the list on www.neilbowers.org (or http://www.neilbowers.org/macperleditors.html) At the moment this is based on a skim of the most recent thread, and the relevant pages. I'll update this if emailed additions (to me please, not the list :-) Neil This also just came up on the OS X talk list, and another suggestion which is getting good comments is TextMate: http://macromates.com/ Ian > Tired of seeing runaway threads on this topic, I've created a page so > that next time [quoted text clipped - 8 lines] > > Neil Being an old Windoze user recently converted to Mac, I wish I could get UltraEdit running on OSX (without having to use VirtualPC). UltraEdit is a great tool. Bruce > This also just came up on the OS X talk list, and another suggestion > which is getting good comments is TextMate: [quoted text clipped - 15 lines] >> >> Neil >> I'd love to hear a convincing explanation from someone why anyone >>would >> use such tools in preference to TextWrangler, BBEdit or Affrus. I can >> imagine they'd make it a chore to write code in us-ascii and either a >> nightmare or an impossibility to deal with non-ascii, but maybe that's >> because I'm just an unreformed Mac user :-) >They aren't free (well BBedit and Affrus), they aren't cross platform >(why learn a different editor for each platform), and they require lots >of clicky. > >I have never logged into a system where I couldn't use vi. (well maybe a >windows box, but it didn't take long to install gvim or cygwin.) In the case in point though he's using OS X so why not use the best tools for the platform you're on? If one day he gets stuck on Atari he'll have to learn vim/emacs/whatever. No point suffering til then :-) Cheers, Regards, Phil. -- Give a man a fish and he can eat for a day Show a man grep and you'll never see him again >>>I'd love to hear a convincing explanation from someone why anyone >>>would [quoted text clipped - 11 lines] > > In the case in point though he's using OS X so why not use the best tools for the platform you're on? If one day he gets stuck on Atari he'll have to learn vim/emacs/whatever. Convince me they are the best tools. I gave you two other reasons why they aren't as good. On top of the fact that it is cross platform. > No point suffering til then :-) I'm not suffering in vim, I would be in those others. > Cheers, > [quoted text clipped - 4 lines] > Give a man a fish and he can eat for a day > Show a man grep and you'll never see him again Give a man a fish, and he will grill it and drink a beer. Teach a man to fish, and he will sit in a boat and drink beer all day long. http://danconia.org >> I'm thinking that if he's not comfortable with pico maybe emacs is not >> the best idea... > I'd love to hear a convincing explanation from someone why anyone would > use such tools in preference to TextWrangler, BBEdit or Affrus. I can > imagine they'd make it a chore to write code in us-ascii You imagine wrong. There's a reason that emacs and vi have been popular for so many years, and since long before OS X was even thought of. > and either a > nightmare or an impossibility to deal with non-ascii, but maybe that's > because I'm just an unreformed Mac user :-) If you put non-ASCII in your code you're doing something wrong. Language-specific stuff - including English - belongs in a seperate resource file if you care about internationalisation. SignatureDavid Cantrell | Hero of the Information Age Nuke a disabled unborn gay baby whale for JESUS! >> I'd love to hear a convincing explanation from someone why anyone >>would [quoted text clipped - 3 lines] >You imagine wrong. There's a reason that emacs and vi have been popular >for so many years, and since long before OS X was even thought of. [...] I sense the perennial 'when I was a lad and that's all we had' hypothesis coming up but was this the reason for their popularity? If so it's kind of lame seeing as we know have alternatives that work very well and more intuitively on their given platform (i.e. OS X) Cheers, Regards, Phil. >>>I'd love to hear a convincing explanation from someone why anyone >>>would [quoted text clipped - 5 lines] > I sense the perennial 'when I was a lad and that's all we had' hypothesis > coming up but was this the reason for their popularity? The reasons that they were popular and still are have already been listed. All to do with utility and nothing to do with the fact that I used to have to work 25 hours a day down pit for nowt but a bag of gravel AND I WAS GRATEFUL FOR WHAT I GOT. > If so it's kind of lame seeing as we know have alternatives that work > very well and more intuitively on their given platform (i.e. OS X) OS X is only one of many platforms I use. This is the case for most programmers whose opinions I respect. I want my most important tool, the one in which I write the code that earns me the money I need for buying whisky, to work consistently everywhere that I work (OS X, Linux/x86, Linux/Sparc, Solaris, Unicos, Irix, OpenBSD). Until TextWrangler, BBEdit, and Affrus work consistently in all those places - and yes, that includes over slow network connections - they are unworthy of consideration. But if you want to limit yourself to just one platform, you go right ahead. SignatureDavid Cantrell | Hero of the Information Age It doesn't matter to me if someone else's computer is faster because I know my system could smash theirs flat if it fell over on it. -- (with apologies to Brian Chase) [...] >> If so it's kind of lame seeing as we know have alternatives that work > > very well and more intuitively on their given platform (i.e. OS X) [quoted text clipped - 10 lines] >But if you want to limit yourself to just one platform, you go right >ahead. As with most editor wars this is going off on a tangent. This one platform is OS X with which this list concerns itself and the original questioner was expressing doubts about using command line editors and therefore asked about alternative GUI ones. Whether or not they are worthy of your consideration because they don't work on Linux/x86, Linux/Sparc, Solaris, Unicos, Irix, OpenBSD or Playstation is neither here or there in this context although I very much enjoyed hearing your opinion. Also I *can* use vim... Cheers, Regards, Phil. Hi, all, Thanks for all the replies. They are all very useful to me. I have downloaded TextWrangler and used it for a short while. It satisfies all my need right now. In fact, I feel it is better than the shareware I used to use for editing Perl scripts on Windows. TextWrangler is free from Bare Bone Software, which also sells BBEdit. I have learnt vi before. Than I used MPW shell. I never get really comfortable with vi. But I can still edit a file when it is needed on a UNIX. But it is clumsy for me. Some friends have recommended vim and emacs to me. And one of the reasons is he can remotely edit a text file very easily. Maybe one day I will learn emacs or vim as a challenge. One more thing that I feel uncomfortable with is X-window stuff. ted zeng Adobe Systems >Then I used MPW shell. If you liked the MPW shell you should purchase the full BBEdit package. Their worksheets are the closest thing you can get, on OS neXt, to MPW with executable shell commands from within the worksheet. Two differences are frustrating: You can't redirect output to another open worksheet the way MPW did and environment variables set from one worksheet will not be recognized in another. But it beats running MPW in classic mode. SignatureApplescript syntax is like English spelling: Roughly, but not thoroughly, thought through. It seems to me, that vi and vim are very similiar. I actually thought they were the same. What is the difference? Joe. > Hi, all, > [quoted text clipped - 20 lines] > ted zeng > Adobe Systems [mangled quotation style revised :-) c.d.] > > I have downloaded TextWrangler and used it for a short while. It > > satisfies all my need right now. In fact, I feel it is better than > > the shareware I used to use for editing Perl scripts on Windows. > > TextWrangler is free from Bare Bone Software, which also sells > > BBEdit. TextWrangler seems to be a very good editor, and if you grow out of it, BBEdit will be there waiting for you as a superset of TW. It's also worth taking a look at SubEthaEdit though, if only for the extremely clever & useful collaborative editing feature that allows multiple SEE users to work on the same document at the same time. The people working on the document can discover each other automatically if you're on the same local network, or you can connect to remote users over the internet if you have their address. As an example, I've used SEE to edit a shared document from home and at work at the same time (with help from VNC) or asynchronously (to work on the file at work, then pick up where I was when I get home). This isn't a capbility I'm aware of in any other editor, on any platform, and it's pretty much the only thing that would ever make me want to switch away from usign Vim as my main text editor. If you're collaborating on documents with other OSX users, this can be a great way to assist that. At my job, we've got half a dozen OSX users that have switched away from BBEdit to SEE just so they can collaborate this way, and they've been really happy with for the past few months. > It seems to me, that vi and vim are very similiar. I actually thought > they were the same. What is the difference? Vi was a very early full-screen UNIX editor going back to the 70s or so. Vi today is basically the same program it wass 20 or more years ago. Vim is "Vi IMproved", a completely new program that both implements all the functionality of classic Vi while extending it with lots of features that came along later with editors like Emacs: multiple levels of undo, command history in the ex subshell, etc. Plus, it includes an optional graphical mode that runs natively on X11, Windows, and OSX; it doesn't make Vim as simple to use as TextWrangler / BBEdit / SubEthaEdit / etc, but it's a lot more friendly than the original Vi ever was... SignatureChris Devers "vim" is "vi improved", a rewritten version of the original vi editor written many many years ago. http://www.vim.org/about.php The one real advantage to vi-type editors compared to other editors is that they enable you to edit without taking your hands off the home keys. They are, however, extremely difficult to learn. I have never recommended vi to anyone who wanted to learn a new editor from scratch. But for those of us who did learn vi back in ancient days and are comfortable with it, vim does have that advantage, and also advanced (to me) features like syntax coloring. The only integrated development environment I ever used was the one in QuickBASIC, but even that was extremely useful. I haven't tried Affrus yet, but I am tempted. Even if I do have to use cursor keys. I think it's probably a mistake to base a choice of tool on its availability in an environment you're not using. Perl is not just for professional programmers who expect to learn lots of different operating systems and work on them all. If someday one finds oneself programming seriously in some way on another system, one can learn the tools that are appropriate then - tools which may not even exist today. > It seems to me, that vi and vim are very similiar. I actually thought > they > were the same. What is the difference? SignatureAaron Priven, aaron@priven,com, http://www.priven.com/aaron >The one real advantage to vi-type editors compared to other editors >is that they enable you to edit without taking your hands off the >home keys. Both TextWrangler and BBEdit, which for Perl purposes are virtually identical (it's the html stuff that's missing in TW) are configurable to the nth degree as regards keystrokes and can be customised, I am sure, to emulate the behaviour of vim or whatever as regards keystrokes. Any key combination can be used to perform any operation within the document, the application or beyond. Pods can be displayed for selected terms of module names at a single keystroke etc. etc. The most involved sequences of tasks can be performed with a single keystroke. In a short time a user can set up the application to respond as he chooses to commands that he chooses, which might be vim-like or might not. JD > Both TextWrangler and BBEdit, which for Perl purposes are virtually > identical (it's the html stuff that's missing in TW) are configurable [quoted text clipped - 7 lines] > to respond as he chooses to commands that he chooses, which might be > vim-like or might not. <sigh> I should let this thread die a natural death, but...this post illustrates the silliness to which editor wars always stray. First, a response to the "anything vi can do, BBEdit can do better": I suspect the hardest commands to replicate would be the simplest: move the cursor to the next word, line, block, or backwards, move to end of line or paragraph, etc. Even things that can be sort of replicated, like a search-and-replace sequence over the next 10 lines, would require a bunch of extra tabs to move from dialog field to dialog field, even assuming the entire search-and-replace dialog can be navigated mouseless (I don't know or care). Making the process as quick as vi (assuming a skilled operator of vi) would likely be impossible. For you, no doubt BBEdit is quicker, which explains why you might prefer it. But, even if you could make BBEdit look like vi, why? If I love vi so much, would I buy a commercial program and spend hours (it would take it) configuring it to look like another program I could have for free and without the work? Furthermore, let's say I ssh into some remote box and want to edit some quick Perl or shell script or config file on the remote box. I'm back to using vi. Yes, in some cases I could run X or VNC or RemoteDesktop or some other remote GUI tool, but it's often overkill, like hopping in your SUV and driving twenty feet to your mailbox to check the mail. I own BBEdit and love it. For me personally, I prefer editing code with a mouse-based editor, and I don't feel the need for editor consistency. But for some tasks, you can do it in vi before BBEdit could even launch, even if it were an option. And I've seen people with greater skills in vi, for whom it is the best choice in many more situations. Bottom line: people have their preferences, and their preferences may actually make sense (ie be optimal) for their circumstances and usage. If you are annoyed with your current editor, check out some of the editors mentioned. Let's get back to Perl and MacOS X. <sighing at the futility of the request> -- MattLangford >Some friends have recommended vim and emacs to me. And one of the >reasons is he can remotely edit a text file very easily. This has been mentioned a few times, but of course TextWrangler/BBEdit both support Edit via FTP/SFTP, so presuming you are SSHing to your target machine, then you can easily edit remote files with TextWrangler/BBEdit. For example, on the target machine while logged in via ssh, you can do this: ssh peter@mymac.com bbedit sftp://peter@remotehost.com/perl/Peter/Tools.pm I'll leave as an exercise to the perl hacker as to how to have to set up[ an alias and script to do this by typing rbbedit Tools.pm Enjoy, Peter. Signature<http://www.stairways.com/> <http://download.stairways.com/> > >Some friends have recommended vim and emacs to me. And one of the > >reasons is he can remotely edit a text file very easily. [quoted text clipped - 7 lines] > > ssh peter@mymac.com bbedit sftp://peter@remotehost.com/perl/Peter/Tools.pm I should here plug cenotaph. It's something Matthias Neeracher wrote, and then I ported it to Mac OS X. It's a client-server. The server, cenotaph, runs on your local Mac, and the client, ceno, runs on the remote boxes you're using as your editor. So you type: ceno somefile on the remote box, and somefile pops up on your local box, in your editor. When you're done editing it, cenotaph sends it back through the open connection to the client, where it is then saved. Any editor works, in theory: cenotaph will execute the editor and wait for it to return, so it pretty much requires an editor that runs in your GUI. By default, it uses BBEdit (via '/usr/bin/bbedit -w'). It's a useful tool to have, especially when you can't get direct scp/sftp access to a machine (such as in my work environment, where I have to go through a gateway first to get to any of the other machines, so I either use a remote command line editor, or this). There's no security, because I've never needed it and no one else seems to be using this and therefore no one really cares, but in theory if someone knew your IP address and that you were running cenotaph, they could open any number of files to your editor. :-) Anyway, it's on SourceForge.net if you care. http://sf.net/projects/pudge/ SignatureChris Nandor pudge@pobox.com http://pudge.net/ Open Source Technology Group pudge@ostg.com http://ostg.com/ >>>>> "Peter" == Peter N Lewis <peter@stairways.com.au> writes: Peter> This has been mentioned a few times, but of course TextWrangler/BBEdit Peter> both support Edit via FTP/SFTP, so presuming you are SSHing to your Peter> target machine, then you can easily edit remote files with Peter> TextWrangler/BBEdit. And of course Emacs can do this as well. For a very long time. :) SignatureRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! >If you put non-ASCII in your code you're doing something wrong. >Language-specific stuff - including English - belongs in a seperate >resource file if you care about internationalisation. Uhm, the Perl I use uses UTF-8 by default. UTF-8 and Unicode have nothing at all to do with language, whatever you mean by that; and if I'm using a text editor that allows me to include Chinese and Ancient Greek in a perl script, as I do, and have them displayed as such for my convenience I am doing nothing wrong at all, since the script is all in UTF-8. I think you are talking of a different century. JD >> If you put non-ASCII in your code you're doing something wrong. >> Language-specific stuff - including English - belongs in a seperate >> resource file if you care about internationalisation. > Uhm, the Perl I use uses UTF-8 by default. UTF-8 and Unicode have > nothing at all to do with language, whatever you mean by that; Fair point - I don't believe any language uses the SNOWMAN character that some moron thought should exist in a character set. > and if > I'm using a text editor that allows me to include Chinese and Ancient > Greek in a perl script, as I do, and have them displayed as such for my > convenience I am doing nothing wrong at all, since the script is all in > UTF-8. I think you are talking of a different century. If it's for your convenience, that's fine. If you want to contribute your code to someone elses project, or you want others to work with you on your project, then insisting that everyone else use your choice of encoding, which may not render at all on their hardware even if they were to jump through the appropriate settings hoops, is just plain rude. You also open yourself up to confusion between o and ο - on which subject, see recent security advisories. SignatureDavid Cantrell | Reality Engineer, Ministry of Information emacs: for a brave GNU Word -- cdevers, in #london.pm >If it's for your convenience, that's fine. If you want to >contribute your code to someone elses project, or you want others to >work with you on your project, then insisting that everyone else use >your choice of encoding, which may not render at all on their >hardware even if they were to jump through the appropriate settings >hoops, is just plain rude. At least I have never been offensive to an expectant mother whale :-) and the encoding I use, without exception, is the default encoding of the Perl language, so I have the honour to share my manners with Larry Wall and other very nice people a long way from England. JD Apologies for fanning the fires, but this hits kind of close to home ... > [...] > > and either a [quoted text clipped - 4 lines] > Language-specific stuff - including English - belongs in a seperate > resource file if you care about internationalisation. Resources have to be edited with something, and it is often useful to be able to use REs on them. Also, making systems and apps universal is trying to solve a problem that shouldn't be solved, even if the tools are useful. Even if the core engines of, say, a medical system can be universal, there are huge pieces of functionality that should _not_ be so. If you try to run a Japanese clinic the way an American hospital or clinic is run, you're not going to help very many patients. Likely to scare a number of them, in fact. The guys that build the local stuff should work in their own language as much as possible, and that includes not just comments, but, if possible, identifiers, syntax, and grammar. Otherwise, they tend less to understand what they are doing and more to think it's all just a mathematical game. And they tend not to really understand re-factoring if it doesn't work on symbols in their own language. Right now, comments are about all that can be dependably worked with in non-Latin characters, but even those, it's useful to have a full and accessible set of RE-type tools to work with. >> I'm thinking that if he's not comfortable with pico maybe emacs is >> not the best idea... [quoted text clipped - 4 lines] > either a nightmare or an impossibility to deal with non-ascii, but > maybe that's because I'm just an unreformed Mac user :-) Two points, or maybe three -- One, vim can be customized to handle mult-byte characters. Emacs, can, too, from what I hear. I'm personally not satisfied with the results, but it does "work", even if it's rather clumsy. I have the impression that pico can also be customized, since there are a number of Japanese people who use it. The other, vi is, as has been mentioned, almost always there, and it's much easier to use than ed. Also, vi inherits a lot of powerful macro processing capabilities from ex/ed that are somewhat arcane, but still useable. If you're comfortable with vi and can keep track of the arcane syntax, it pretty much lets you do everything you can do in mpw. I personally use whatever's handy, but when I edit the files under /etc, I usually don't really want to waste the time fiddling with permissions and such. And if I have to type the file path in by hand anyway, I might as well open up a terminal and use vi. >> I'm thinking that if he's not comfortable with pico maybe emacs is >> not the best idea... [quoted text clipped - 4 lines] > either a nightmare or an impossibility to deal with non-ascii, but > maybe that's because I'm just an unreformed Mac user :-) Personally, because I learned Emacs in 1986, so the control keys are hard-coded in my brain :-) [..] > Personally, because I learned Emacs in 1986, > so the control keys are hard-coded in my brain :-) [..] Given that ted, you don't mind me calling you ted, had asked about coding in perl - and on an OSX box, then the obvious first choice is BBedit. They have done a lovely job of being Darwin Aware and Perl Friendly. When I am not on my darwin box, I use 'vi'. I will confess that learning emacs to use on 1200 baud modems was just all the rage in the 80's - but then we got real networked computers. So basically I 'vi' on the other boxes only when I can use NFS/SMB to mount the directory onto my Darwin Box. And not meaning to pick on you Andy, but of course one has to, where ever do you hide the extra digits required to do Emac's in it's Native Mode where one only needs to do a chord combo of some n-gagillion keys. Most of the Terran's I have meet have problems with that. cf: <http://www.wetware.com/drieux/OldWorld/screeds/LiNox.html> ciao drieux --- Fun is having the CTO decide that we need to shift to 17" Powerbooks so we can run BBedit for creating code. >> I'm thinking that if he's not comfortable with pico maybe emacs is >> not the best idea... [quoted text clipped - 4 lines] > either a nightmare or an impossibility to deal with non-ascii, but > maybe that's because I'm just an unreformed Mac user :-) Easy. You're ssh'ed into a box. Emacs makes the ONLY sense. (OK I suppose you could use pico or that one that starts with the letter after U. -- Lou Moran ellem52@mac.com http://ellem.is-a-geek.org:5280/ http://homepage.mac.com/ellem52/ I think there is a version of TSO that runs in unix, and on Windoze. This is for the very strong only. Joe. >>> I'm thinking that if he's not comfortable with pico maybe emacs is >>> not the best idea... [quoted text clipped - 13 lines] > http://ellem.is-a-geek.org:5280/ > http://homepage.mac.com/ellem52/ >> I will install the Xcode and see how it goes. > > You know where to find it? FWIW, you can probably get the XCode CD from an AppleStore. I stopped by the Cambridge store one day and they literally said "take it". Saves a long download.. Mike |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.