The failure modes of rsync
-
Just saying. I came across an explanation of the difference between hyperbole and lying (because on the surface there appears to be no difference) whilst looking for a word that politicians use to admit that something they said was a lie without actually admitting they lied.
Not that I am saying anybody is lying here, but it seemed an ideal time / space to pass on that inadvertently learnt wisdom.
Edit: I think a classic example of this would be some female politician (running for President IIRC) claimed that she had placed herself in jeopardy, in the line of duty, when she visited "somewhere" where the local bad hats tried to snipe her.
-
Duly noted
-
alias that to lf if you must but when i'm in the habit of building bash scripts on the fly in the command line and your aliases change the default behavior of the commands i'm going to be writing sed and awk scripts around.... that's not going to fly
Except… if you're using
lsin a script you're virtually always Doing It Wrong™ in the first place. Either you should use an appropriatefindor (if you're not so bothered about spaces or other evil characters in filenames) plain oldechofor scripts. Alllsadds that a script could possibly want to use is sorting, and scripts usually don't need that sort of thing.
-
when i'm in the habit of building bash scripts on the fly
Hey, I do that too!
Don't think I've done so on LS though.
-
Except… if you're using ls in a script you're virtually always Doing It Wrong™ in the first place.
If this is a written thing that is sticking around on the system, absolutely
if this is a quick one liner in my shell to do a thing once, not so much.
i'm talking about the second case.
-
if this is a quick one liner in my shell to do a thing once, not so much.
I use
findeven in that case.
Or
for foo in *.txt; do ...; donemore commonly.
-
Seems much easier than threatening violence against random other developers for the audacity to want to optimize their environment...
No, that other thing sounds like work. This OTOH, could be fun.
-
Except… if you're
using lsparsing user-targeted output in a script you're virtually always Doing It Wrong™ in the first place.FTFY.
-
@blakeyrat said:
Oh so when you said "CMD" what you meant is the console window.
When I say cmd, I mean whatever opens up when I type "cmd" in Start menu search bar and hit enter.
So in effect you are saying that the container and the containee are the same thing. So an XTerm is bash if bash is running in it?The console window is a severely funky thing (or was back in the day, maybe it is less funky now), but it is a container for the console associated with a running program (if it has one). Windowed applications (i.e. they start in WinMain()) like, say, Word, Excel, Visual Studio, Paintshop, etc. don't normally have console windows, but they can call AllocConsole() to create one. Console applications (i.e. they start in main()) such as CMD, PowerShell, and the classic Windows telnet and ftp clients do have a console window, but they can call FreeConsole() to get rid of it.
CMD.EXE, on the other hand, contains the classic Windows NT command processor, and it is a console application. Improving the console window will improve the user experience with all console applications, but is not actually an improvement to those applications.
-
So in effect you are saying that the container and the containee are the same thing. So an XTerm is bash if bash is running in it?
When I run "xterm", an XTerm window pops up. When I run "bash", I get dropped to Bash shell. When I run "cmd", something shows on my screen, and thus I call this something "cmd".
-
When I run "bash", I get dropped to Bash shell.
Wait, so when you run "bash" your X server completely gives up the display and switches your monitor to 80x25 text mode? Man, I feel so sorry for you...
-
When you type "cmd", two things appear on your screen. One is a console window, that is, a container for console programs. The other is a console program, cmd.exe, inside the console window. You are saying that the console window and the console program are the same thing. Calling the console window "cmd" because you typed "cmd" and it appeared does not make it "cmd".
-
Wait, so when you run "bash" your X server completely gives up the display and switches your monitor to 80x25 text mode?
No, I have to do it manually with CtrlAltF2. Without this, running bash has (obviously) no effect, because (obviously) it's not attached to any terminal emulator.
-
When you type "cmd", two things appear on your screen. One is a console window, that is, a container for console programs. The other is a console program, cmd.exe, inside the console window. You are saying that the console window and the console program are the same thing. Calling the console window "cmd" because you typed "cmd" and it appeared does not make it "cmd".
OK, you win. I can't argue with facts.
-
That's just because windows, unlike your linux desktop manager, is smart enough to start a console window when the program you're invoking needs it.
-
That's because in Windows, console window is hardcoded everywhere over the place, and Linux keeps everything simple.
-
-
Yes, seriously. I omitted the obvious details for brevity.
-
I think you're either lying, or don't know what Bash shell (on its own, without any supporting programs) actually is.
-
Bash shell (on its own, without any supporting programs) exits immediately after start because it cannot operate without backing terminal.
-
So in your own words, you're telling us when you run 'bash', it starts and then exits immediately.
One might ask, "what is the point of running 'bash' at all, then?" And it would be a good question.
But the answer would disappoint. Because you are a moron.
-
So in your own words, you're telling us when you run 'bash', it starts and then exits immediately.
It only exits immediately when you run it, quote, on its own, without any supporting programs, end quote. The obvious detail that I omitted is that obviously I don't run it like that.
-
One might ask, "what is the point of running 'bash' at all, then?" And it would be a good question.
In context, this sentence is bullshit and strawmanning. But taken out of context, I can actually agree with it. There's no point to ever run Bash. Zsh is far superior.
-
So in your own words, you're
massively out of context here, ya jumpy-ass bulldog. He's saying far as I read, before you did that oh-so-clever little strawman (or maybe you just suck hard at understanding things), that 'bash' will die if preconditions aren't met. Don't believe he was saying he does that a lot. But then again, you I suppose expect programs to limp along shitting the bed for a few minutes in such scenarios.Christ you are such a waste of air the second you open your mouth when UNIX is anywhere nearby, what is _wrong+ with you, oh wait, the answer disappoints, you fucking useless asstard.
-
windows, unlike your linux desktop manager, is smart enough to start a console window when the program you're invoking needs it
Linux desktops, unlike Windows, don't go to stupid lengths to make console I/O its own special thing.
Any Unix desktop application can write whatever it likes to stdout and stderr, or attempt to read stdin, just like any other program. If the "Run in terminal" option is checked in the application launcher, the application gets launched with stdin, stdout and stderr connected to a terminal emulator. If not, they're connected to /dev/null by default.Many Unix desktop applications spew quite useful debug information to stderr. With the default launcher this is discarded but it's easy to see it in a terminal or redirect it to a logfile if you want to look at it.
I've often wished that Windows applications would do the same thing, but because Windows puts console I/O under the control of the application rather than the OS, very few of them do; nobody wants to confuse 99.99% of the user base with normally-irrelevant scrolling text.
-
Bash shell (on its own, without any supporting programs) exits immediately after start because
it cannot operate without backing terminal.quitting at EOF on its stdin is sane behavior.pcbe
-
Any Windows desktop application can write whatever it likes to stdout and stderr, or attempt to read stdin, just like any other program. If its parent has an inheritable console handle -- say,
cmd.exefor example -- the application gets launched with stdin, stdout and stderr connected to a console window. If not, they're connected toNULby default.Many Windows desktop applications spew quite useful debug information to stderr. With the default launcher this is discarded but it's easy to see it in a terminal or redirect it to a logfile if you want to look at it.
The reason console I/O is its own special thing in Windows partially has to do with 1991-era processors' inability to switch between privilege levels quickly, and partially has to do with the guts of "New Technology Virtual DOS Machine" support, the details of which I used to know but have long forgot.
ETA: You can, if you're so inclined, use
binutilsto flag an app as using the console subsystem, in which case it automatically gets a new one if it doesn't already have one.
-
Linux desktops, unlike Windows, don't go to stupid lengths to make console I/O its own special thing.
What does that mean?
Any Unix desktop application can write whatever it likes to stdout and stderr, or attempt to read stdin, just like any other program.
Much like Windows, them.
If the "Run in terminal" option is checked in the application launcher, the application gets launched with stdin, stdout and stderr connected to a terminal emulator. If not, they're connected to /dev/null by default.
So the Windows behavior is "stdin" and "stdout" are created if/when the application attempts to send something to them.
The Linux behavior is the user must determine whether "stdin" and "stdout" should exist at the time they launch the program.
And this is some kind of huge philosophical break that makes Windows super-crappy and awful and Linux far superior and run only by handsome geniuses. Because... uh. Because.
Many Unix desktop applications spew quite useful debug information to stderr. With the default launcher this is discarded but it's easy to see it in a terminal or redirect it to a logfile if you want to look at it.
So exactly like Windows, then.
I've often wished that Windows applications would do the same thing,
Nothing's stopping them.
but because Windows puts console I/O under the control of the application rather than the OS, very few of them do; nobody wants to confuse 99.99% of the user base with normally-irrelevant scrolling text.
And why wouldn't the application itself be the ultimate authority on whether the application supports console I/O at all?
How does it make any sense at all with burdening the user to start the application with this special flag, basically performing "guess and check" on every application they own to see if it supports this feature that's utterly useless for 99.9% of users? That would take hours and hours, and you'd still never know "for sure" (since the application could stay mute until some user action is taken. You'd have to explore every single code-path to be sure.)
I know Linux people don't give a shit about usability, but you're lamenting that Windows has the far and away more logical solution to this problem and crying that you can't guess-and-check all your applications for hours or days to figure out if they use the feature or not. WTF.
BTW Windows applications that use the auto-created console (by being launched from Explorer) don't *show it on screen" unless explicitly instructed to. So the application wouldn't be confusing the user in any case. Don't confuse "it exists" with "it's shown on screen", those are very different things.
-
Doesn't ls have some magic BS where it checks whether it is actually outputting to the screen or another application and changes its output accordingly?
-
Doesn't ls have some magic BS where it checks whether it is actually outputting to the screen or another application and changes its output accordingly?
Yes. Except the
isatty()call isn't magic BS.
-
lsdisables its "fancy" formatting when it's not connected to a terminal because sometimes you want to keep ls output as text. Usinglsin scripts isnot good practicejust a failure waiting to happen. This page on parsing ls output sums it up quite nicely.Shell scripting is a form of witchcraft that would've been outlawed long ago if doing so wouldn't break everything. Of course I still practice it because that's how I talk to computers. Switching to another language when automating simple tasks is too cumbersome.
It would be nice if the shell tools could pass around pure data and have it formatted only when it hits the shell. Maybe some day there will be an acceptable implementation of that strange concept :-)
-
shell tools could pass around pure data and have it formatted only when it hits the shell
Isn't that exactly what powershell does? Passing around pure objects and only formatting it to the shell when there is nothing else to do? And doing that by using a dedicated cmdlet no less
-
We don't do PowerShell around here.
-
Just rewrite everything in pure C then! Or Java even!
-
C it is! What is this Java you speak of?
-
I believe the canonical next step is actually Perl.
-
Can we go all the way down to assembly? I love me some assembly
Granted I've never actually used any REAL assembly so...
-
To this rant I am re-reading, I should add:
Linux desktops, unlike Windows, don't go to stupid lengths to make console I/O its own special thing.
Windows just automatically and silently creates a console as-needed by an application. The user (or developer, really) never has to think about it, it just happens.
Linux requires the user to check a box in a dialog for the console to exist at all, and once checked the console always exists regardless of what the application is doing.
But in Windows, the console is "a special thing", and in Linux it is not.
Your brain is backwards and upside-down.
-
Isn't that exactly what powershell does? Passing around pure objects and only formatting it to the shell when there is nothing else to do? And doing that by using a dedicated cmdlet no less
Congratulations, you got the joke.
-
Well damn, I'm oblivious
But in Windows, the console is "a special thing", and in Linux it is not.
It is special, to a linux aficionado. They are not used to functionality being automatically handled by the system in a convenient manner.Of note, "Special" =/= Bad
-
-
We could write the string formatting and parsing codes in assembly for reliability and ease of maintenance. I read in my free C book that C has troubles with string handling.
-
We could write the string formatting and parsing codes in assembly for reliability and ease of maintenance.
It's easy by comparison with just writing machine code directly…
-
I think you're being sarcastic here
Well I guess you haven't read how unreliable C strings are. Wouldn't want to have these in our implementation.
-
I think you're being sarcastic here
No and yes. No, assembler really is much easier than direct machine code. Yes, I was still messing with your head. :D
-
Many Unix desktop applications spew quite useful debug information to stderr. With the default launcher this is discarded but it's easy to see it in a terminal or redirect it to a logfile if you want to look at it.
In my experience, by default it is spewed all over the Ctrl+Alt+F1 console, which is, naturally, not visible because it is hiding behind the graphical desktop. Even if the program is by preference a windowed application, it will often do this instead of popping up a message box or similar. The problem, of course, being that if the problem occurs before the application creates its main window, it barfs all this invisible text and then quits. That is, in UX terms, it doesn't run at all.OK, sure, a Win32 graphical subsystem program can do that, but because by default it doesn't have a console to barf in, programmers tend to barf into message boxes instead, giving the user a bit more clue of what is going on. Well, a bit more information, even if that information is sufficiently techish that Joe Average dismisses it as "When I run X, it puts up some computer garbage then quits".
Faced with the failing Linux program, Joe Average dismisses it as "Something's wrong. When I try to run X, nothing happens. My computer is broken."
-
OK, sure, a Win32 graphical subsystem program can do that, but because by default it doesn't have a console to barf in, programmers tend to barf into message boxes instead, giving the user a bit more clue of what is going on. Well, a bit more information, even if that information is sufficiently techish that Joe Average dismisses it as "When I run X, it puts up some computer garbage then quits".
Faced with the failing Linux program, Joe Average dismisses it as "Something's wrong. When I try to run X, nothing happens. My computer is broken."
Users actually don't really distinguish these two. They still call for tech support and blame someone other than themselves (often justifiably, though not always).
-
Null terminated strings are hard, let's do pascal style strings instead
-
Yea, Pascal strings are cool. This way we can't run into undefined behavior you often get in C. Of course we'll have to adapt a bit for Unicode but with a powerful assembly language, this is easy. I find the simplicity and power of Pascal Strings exempla
-
Of course we'll have to adapt a bit for Unicode
Of course. You can now have up to 65535 characters in a string! Lucky you…
