Slashdot Mirror

https://mywiki.wooledge.org/Ft...

This article convinced me that FTP is, in fact, worse than HTTP.

That might be acceptable in PowerShell, since the 'ls' there is a lie, but if you're trying to parse output from a real 'ls' in a real shell script, you're doing it very, very wrong indeed. See this page for details: Why you shouldn't parse the output of ls

tl;dr: File names are slippery sumbitches. Use 'find' instead.

That's just it, you can't write a client to handle the protocol. Or, more specifically, you can, but that protocol doesn't include the information necessary to write a client. The protocol was designed to be typed by hand and interpreted by a human, not software. When an FTP client shows you a file listing, it is guessing at how to interpret the file listings.

As for firewalls, no, there are problems there as well. Firewalls have to actively watch for FTP connections and treat them specially, and even when they do, they can't get it completely right because the protocol is fundamentally broken.

Don't take my word for it, read what the people who have implemented FTP have to say on the matter: 1 2.

But when you're still providing us with Windows XP in 2011, you are doing it wrong.

Yeah, sure, because Windows 7 can do _so much more_ than Windows XP. Really, there are just a few new features that could enhance productivity for your average user, so yeah, it's totally worth it to throw away stable and tested system and drop $many bucks for an upgrade to all new and better Aero theme^W^WWindows 7.

I may not like that I can't just install Linux, but I understand why you can't let me! But in that case, you need at least to let me have Cygwin or something.

Why? Really. 99.9% of things you can do in Linux and you can do in Cygwin, but not on Windows are developing in languages that don't have a stable Windows implementation - in which case you're surely in a wrong place, because either they don't know what they're doing, making you develop on Windows when they really need Linux, or you don't know what you're doing, trying to drag a "new and cool language" where it's not needed.

Anyways, what you should do is come to your boss and/or the IT and tell them "I need to do X". They'll figure it out.

And no, "I need to install Cygwin" is not a reasonable first request.

Pay no attention to the troll, it lies. I notice you said this was personal, as in, not a non-profit. Anyways, non-profits have no lesser need of stability.
Debian's testing branch is something that they are, well, testing. As in, they're not sure it works. One offhand combination of installing scheme9 and apache-mod-lisp could bring things to a grinding halt. If anyone other than yourself is expecting it to be available in the morning, use debian stable. Heck, if you'd like it to be available in the morning without being up part of the night, use debian stable.

As for the CLI, I've got news you might think bad, but it's not. Administering a LAMP stack without basic familiarity with a shell is like using a web browser without knowing what a scrollbar is - you may be able to do stuff, but not a lot, and not well. The tools that debian includes are command line oriented (as in, no webmin) because point-and-click interfaces require pointing and clicking, and are truly resistant to automation. Automation makes life easier, freeing up time better spent with wine and women (and/or moonshine and men, depending).

The good news is, shells are not terribly difficult to learn the basics of, though it is possible to go into very intricate depth. If you settle on bash, I recommend visiting http://mywiki.wooledge.org/BashFAQ once in a while.

You really need to read this essay about filenames, as well as these two bits about parsing the outputs of ls and ps. In short: correct and secure work with filenames is made difficult by certain features of shells and their default configuration, and the output format of common tools (including ls) makes their output literally impossible to parse in a correct and secure manner. Parsing the output of ps is a very bad idea for similar reasons. It's fine if you're just doing one-liners for simple, everyday interactive work in the shell, but if you write shell scripts and don't understand these issues, you've likely been writing buggy, incorrect, insecure and exploitable code.

I've personally never used PowerShell. My solution to these difficulties has always been to learn to do things properly regardless of the difficulty. While I don't know enough about it to be convinced that it would be a proper solution, I can imagine many ways in which the idea of passing objects instead of text may make things easier. If you can't see why, you need to learn a lot more about shells and their issues. I'm not trying to be patronizing here or anything; it's just that shell scripting is a lot more complex than people typically realize, and such misconceptions cause security holes.

You really need to read this essay about filenames, as well as these two bits about parsing the outputs of ls and ps. In short: correct and secure work with filenames is made difficult by certain features of shells and their default configuration, and the output format of common tools (including ls) makes their output literally impossible to parse in a correct and secure manner. Parsing the output of ps is a very bad idea for similar reasons. It's fine if you're just doing one-liners for simple, everyday interactive work in the shell, but if you write shell scripts and don't understand these issues, you've likely been writing buggy, incorrect, insecure and exploitable code.

I've personally never used PowerShell. My solution to these difficulties has always been to learn to do things properly regardless of the difficulty. While I don't know enough about it to be convinced that it would be a proper solution, I can imagine many ways in which the idea of passing objects instead of text may make things easier. If you can't see why, you need to learn a lot more about shells and their issues. I'm not trying to be patronizing here or anything; it's just that shell scripting is a lot more complex than people typically realize, and such misconceptions cause security holes.

Don't mind me, just karma-whoring: http://mywiki.wooledge.org/FtpMustDie

Exactly; this is an interesting analysis that proves the point: http://mywiki.wooledge.org/FtpMustDie

The first rule of shell scripts is "you don't write programs in shell."
The second rule of shell scripts is "you DON'T WRITE PROGRAMS IN SHELL." Seriously. You want perl or some other high level language.
The third rule is to start your script with "#!/bin/bash", not /bin/sh. Your script probably contains bashisms and you don't even know it. What's more, bash has some great features that are only available if you use it explicitly in your shebang.
The fourth rule would be to read the bash faq at http://mywiki.wooledge.org/BashFAQ as it contains many tips and tricks that won't be obvious just by reading the man pages.

As said previously, scripts are scripts and don't often need a GUI. But for grep's sake, make them consistent!!! The only spicing up _really_ needed are some standards:

o output errors to STDERR; normal output to STDOUT
o include (-h, --help) processing - and send it to STDOUT so the help can be piped to 'less'
o use getopt(1) or process-getopt(1) so that options on the CLI parse in a predictable and standard way
o keep it terse except for errors so that the user can easily see if it worked or not without scanning vast output
o provide a --verbose option to help with tracking down those errors

... and the most annoying thing of all - make sure --help _always_ works, even if the script body itself can't - at least the user can then be told about what the prerequisites are.
Head over to http://mywiki.wooledge.org/BashFAQ for much wisdom on how to write better bash scripts.

fork bomb : http://wooledge.org:8000/BashFAQ/059

http://wooledge.org:8000/FtpMustDie

He probably didn't think that because it isn't true.

What is sid?

Sid is the unstable branch of Debian. All of Debian's branches and releases have "code names" which are from the movie Toy Story. For example, Debian 3.0 is code-named "woody". Sid was the kid who broke all the toys. Some people think sid is an acronym for "Still In Development". This is cute, but inaccurate.

From the Debian sid FAQ; http://wooledge.org/~greg/sidfaq.html#1

Have you tested that syntax with the current Mail::SRS module? Unless I'm seriously mistaken, passing the email into a program in .forward passes the entire email.

The current "srs" executable that comes with that module only translates an address, and that address has to be on the command line. The most efficient way to handle SRS rewriting is in the MTA, and there are already patches for a few of them. There's Python SRS, that can be plugged into Exim and sendmail, and there's a similar implementation in Perl that it links to. There is also an implementation for qmail. I haven't seen one yet for Postfix, but I can't see it being that difficult to implement.

In any case, the only sites that really need to implement it are those that do any forwarding or sending of email as if it's coming from a domain other than their own. In the meantime, there's a trusted forwarder list to ease the transition where it's needed.

1 / Email the dev and tell him (gently) what's wrong in your opinion and what should be done. If he has the time, he'll fix it.

Not always.

Give this one a try.

simple javascript, surprised no one has thought of this before.