Yeah, that's what I was suspecting.

I ended up leaning towards "download" being used in the boomer way of meaning any data transfer, whatever the direction, which in this case would more specifically be called an "upload". And that "online" was being used to mean "using a website", even though the local processing is offline.

The alternative fit to the description I had considered was a website you could give an URL, so it retrieves the zip file and allows you to inspect it remotely, and maybe just download some of the contained files, so it deals with the risk and bandwidth issues for you. That would be a different kind of useful, though it'd only be a few days before someone uses it for malign purposes and gets the site operator a no-knock visit from the fuzz, so that seemed much less likely.

I can see a use for an app that can be used where they can't be installed, though.

I'm not missing your points, even as you change them. I've agreed that JS sucks. I've agreed that errors can be more helpful. I'm not trying to argue with you about that. What I have said, from the beginning, is that in the code you originally presented a behavioural change for setMonth will not help you find the problem any faster. Test failures for the wrong output occur just as often as test failures for errors, on exactly the same few days each year. The API change gives no advantage for the specific function this discussion started with in this regard. However, an approach that avoids inconsistency will, because in this particular instance, that is the real source of the problem. That is all.

In that context—the one you started with—it does not matter that there is often good reason to call Date() without arguments. The getMonthName function presented, effectively an array lookup, should produce the same output for any given input every time. It has no reason to engage in any behaviour that varies from day to day.

There is absolutely nothing wrong with getting the current date.

Bluntly, the code you presented fails precisely because it gets the current date where it should create a more specific one, and then fails to deal with that variation appropriately. You can keep distracting yourself with language design decisions, but that won't help you avoid this particular type of problem in the future because that's not where it is.

Getting the current date is often fine. In this specific instance, it is not. That is why the function doesn't work. If you are missing that point, as much as I appreciate your enthusiasm in continuing the conversation, I will take the L (and the code that actually works) and move on.

I agree with you that errors are useful feedback for coders who don't know the ins and outs of an API. And every programmer is in that group at some point. But the difficulty in identifying this particular bug doesn't stem from the API decisions.

Whether Dates throw an error, or work with what they're given, has no bearing on the subtlety of this bug. Either way, tests that don't replace Date will fail to identify it most of the time, and tests that do, based on its use within the function, would be called wrong-headed by many.

Either way, the bug only shows up at the end of months longer than the target month, and that infrequency has nothing to do with the peculiar design choices of the Date API. It stems exclusively from the evaluation of Date() called with no arguments returning different values at different times—behaviour you have not objected to, and which I'd expect to be considered entirely appropriate, in fact its very point—combined with an attempt to use that value, whatever it may be, without due consideration.

Since the month is the only part of interest, there's no reason to allow the other parts to vary at all. Fixing them, as I suggested at the beginning of all this, is the simplest approach, but setting them first, as has also been suggested, would work too.

You can once again complain about JS design decisions and I'll agree about many of them, but, as much as you might like it to be, and as annoying as so many of us think they often are, here it is beside the point. The perniciousness of this particular bug stems from unnecessarily calling a function with inconsistent output and then improperly processing that, instead of using a function call with always-predictable output.

I've tried to point that out in all the ways I can think of, so if it's still not getting through, I give up. And if your acknowledgement was too subtle for my sleepy brain, and I've ended up overexplaining, then I'm sorry.

I was taught that side effects are not so one-sided, and that changing output in response to outside state (such as the date) is also a side effect, a side effect on the function, rather than a side effect of the function, but I'm happy to use other definitions so long as they're commonly understood.

As I said before, though, even if JavaScript did throw an error as you'd prefer, it would still allow your function to have date-based problems. They'd be a bit noisier perhaps but no less present, and just as "well it's worked fine so far". And that's because, as I keep saying, the real problem here is using a function with inconsistent output and not thoroughly dealing with the possibilities. An API change wouldn't alter that. Most of the time it would still let you write bad code.

I also probably agree with you that errors are generally better than silence in response to bad input but, as someone else has said (more or less) it's not always unreasonable to consider "31st [Month]" as 31 days after the end of [Previous Month]. Without throwing errors, this flexibility is possible. Perhaps the creators believed having to mutate the day-of-month first was an acceptable trade-off for that.

The output here lets us know that systemd is running the service file and starting the script just fine. The echoed GPU temperature is making it to the journal, but the gpuTemp variable isn't being updated (staying at 0) because of a problem executing nvidia-settings. Specifically, it wants a display: "The control display is undefined".

You could add a line to the service file:—

Environment = DISPLAY=:0

Although if echo DISPLAY in your terminal gives you a different value, use that. There's a possibility that that will just push one error further down the line, but it's something to try.

Alternatively/additionally, you could try changing the User= line to your own username to see if it picks up the environment your manual executions work with.

You aren't the only one to run into problems trying to automate nvidia-settings. You might end up needing to track down an Xauthority file or use the display manager's initialisation options.

If it works when run manually, but fails via systemd, then you should post your service file.

Take a look at Engineering Mathematics by KA Stroud. It has a step-by-step approach with worked examples that might be useful to you. Even if you don't like the structure, it'll at least give you a comprehensive list of topics.

You wrote this ten minutes after being reminded that "consent" by children is nonsense, in what is still the most approved comment.

If you want to be a successful troll, you are going to have to learn to be less obvious. If you want to discuss topics in good faith, you are going to have to learn that this "just asking questions" approach makes you look like a troll.

Helping one another out is invisibilized, not rare. A good chunk of what I know comes from other people taking the time to explain why something works the way it does and how you can see that for yourself. The rest is from curiosity, experimentation, and hammering away at something until it fits. It's not professionally specialized knowledge.

Admittedly, I have much less experience with i3, so I fired up a virtual machine with Debian 11.6 and installed i3 (along with lightdm) and was able to recreate the problem of .profile not being executed when logging in, so this isn't unique to your particular setup. Great!

Fortunately, this combination does execute commands in ~/.xsessionrc, so I added:—

. $HOME/.profile

to that file, then logged out and back in again. That did the trick for me, with the commands in .profile then successfully modifying the PATH variable (and writing additional lines to the execution log files), so I suggest you try creating/modifying .xsessionrc in the same way.

But those kinds of initialisations belong in .profile (or, if you're using a weird desktop environment, its own configuration file), particularly if you want .desktop files to work. (In .bashrc, PATH will grow longer in each subshell, which shouldn't cause problems but is wasteful.)

So, what desktop environment (GNOME, KDE, Cinnamon, etc.) are you using?

.profile is executed by login shells for the benefit of it and its subshells, and by DEs like Cinnamon for the benefit of .desktop launchers at login.

So, have you logged out and back in again since adding these lines to .profile?

And of course, the .profile has to be executed properly for its configuration to take effect, so it`s useful to know if the problem is with those specific lines, or the file as a whole.

Add:—

date >> ~/profile-execution-log-top.txt
echo $PATH >> ~/profile-execution-log-top.txt

to the top of .profile, and:—

date >> ~/profile-execution-log-end.txt
echo $PATH >> ~/profile-execution-log-end.txt

to the bottom of .profile (use alternative paths as you see fit) to monitor that activity. You can test this by sourcing .profile but the real test is logging out and in again. Look at the time when you do this so you can correlate each action with each timestamp in the log files. If .profile is executed to completion, you should have two files with matching timestamps but different PATHs. If you don't have a matching timestamp in the "end" log file, there's a problem mid-execution. If neither file is being updated, .profile isn't being executed at all.

Are other lines in .profile being executed, or is the whole file ignored? Have you logged out and in again since adding these lines?