Dell Latitute E7240 (without battery etc.) [Solved]

[j2mcgreg]

@Jakob77 wrote:

I don't know why for sure but I assume it is because the new battery needed a long time with the computer in the docking station to charge up to enough volts to clear the error.

A CMOS battery is a lithium button cell, but it is not rechargeable, A more likely answer is that that you were getting false values because the battery was in such sorry state and it took a while for your system to stabilize.

[Jakob77]

j2mcgreg

Thank you. You are right about the battery. My assumption was a bad guess.
So instead I can perhaps imagine a small circuit with a capacitor that was exhausted and slow to come back to life.
A sort of built in automatic punishment for users who wait too long before they fix the CMOS battery. ;-)

[CharlesV]

@Jakob77 Going back to your scripts ... one thing Duke alluded too, that is pretty critical imo is debugging and what I call "working area" .

one script versus two ....

Problem 1:
With one script you see the entire picture. With two scripts you are seeing ONE part.. and then the OTHER part is in that other script. (Which may or may NOT be actually run.) And may or may NOT be seen by you at that time.

Problem 2: While it may seem more complex, the ability for the computer to make the decision about which path to take on "two things in a script" is far better 99% of the time, (once the script is correctly crafted!!) then a novice attempting to decide which script should be run.

Problem 3: Properly crafted, your script should be checking the decision it needs and then taking the proper path *based on that decision* path. This means that the "working the area" is important to understand for *anyone* attempting to know that there even IS a second script.

And no, #2 and #3 are NOT the same - 2 is understanding which method should be used for that circumstance and #3 is understanding there is a choice!

I learned VERY quickly when starting to work with people that are new on computers... that their lack of understanding leads them to choose something they see or hear... and many times has no bearing on what they should be doing. Saying something is "easier for beginners" can be extremely misleading under the initial view of it.

[Jakob77]

CharlesV

Thank you but please make sure this subject about e7240 won't be locked because you continue the script discussion.
And as time goes by I see there really seems to be no end to how high a level we have to be on in MX-Linux just to make a user script execute a simple Terminal command. lol
I don't think you read what I wrote to Duke about two scripts instead of one.
It is not because it is smart from an advanced technical point of view. It is because it is easy for me to remember and that is important if I can't see any output because the screen is blank.
It is also a good side advantage that the formula used is easy to edit for beginners and seniles like me.
If you see dangerous code that will do very wrong things to my hardware or config please don't be spooky about it but very specific with valid arguments. :-)

[CharlesV]

CharlesV

Thank you but please make sure this subject about e7240 won't be locked because you continue the script discussion.
And as time goes by I see there really seems to be no end to how high a level we have to be on in MX-Linux just to make a user script execute a simple Terminal command. lol
I don't think you read what I wrote to Duke about two scripts instead of one.
It is not because it is smart from an advanced technical point of view. It is because it is easy for me to remember and that is important if I can't see any output because the screen is blank.
It is also a good side advantage that the formula used is easy to edit for beginners and seniles like me.
If you see dangerous code that will do very wrong things to my hardware or config please don't be spooky about it but very specific with valid arguments. :-)

I did read what you posted, and I disagree and stand by what I said. .. It is EASIER for people to fall into a trap right here, *thinking* they understand that script X works, and then dont understand why it suddenly doesnt - when they should be NOW be using script Y - all because of a change to what ever.. that the brain needs to understand.

If script Z contained BOTH parts of script X and Y AND WAS setup for the decisions based upon the CODE .. then there is a better change that no misunderstanding will take place on WHAT is supposed to happen. (provided the user that wrote the code understands AND wrote it properly. )

As for locking threads... you are blending two topics and should not be!

[DukeComposed]

It is also a good side advantage that the formula used is easy to edit for beginners and seniles like me.
If you see dangerous code that will do very wrong things to my hardware or config please don't be spooky about it but very specific with valid arguments. :-)

It is EASIER for people to fall into a trap right here, *thinking* they understand that script X works, and then dont understand why it suddenly doesnt

Valid arguments have already been made and rejected. OP is confused about what "easy to edit" really means because he hasn't had to make a serious change yet. There's just no accounting for experience.

OP has made it clear he does not wish to change his scripts, and that's his prerogative. The short and sweet version of this is that constructive advice has been given for how to improve his little examples and it's been summarily dismissed on the grounds it's "too complicated" for a "beginner". Though we should be clear that no one is reverse engineering these xrandr commands looking for inspiration. In two years here the only person with a hard-on for a script adding ~/bin to $PATH has been OP. So we know prima facie which beginner we're really talking about here. These are niche little applications only OP could love and if he's happy with them, I certainly can't force him to rewrite them. They are not manna from heaven. No one here is god's gift to programming.

I feel you and I are wasting our time trying to instill better shell scripting practices here. You can lead a horse to water, but you cannot make him drink.

[CharlesV]

It is also a good side advantage that the formula used is easy to edit for beginners and seniles like me.
If you see dangerous code that will do very wrong things to my hardware or config please don't be spooky about it but very specific with valid arguments. :-)

It is EASIER for people to fall into a trap right here, *thinking* they understand that script X works, and then dont understand why it suddenly doesnt

Valid arguments have already been made and rejected. OP is confused about what "easy to edit" really means because he hasn't had to make a serious change yet. There's just no accounting for experience.

OP has made it clear he does not wish to change his scripts, and that's his prerogative. The short and sweet version of this is that constructive advice has been given for how to improve his little examples and it's been summarily dismissed on the grounds it's "too complicated" for a "beginner". Though we should be clear that no one is reverse engineering these xrandr commands looking for inspiration. In two years here the only person with a hard-on for a script adding ~/bin to $PATH has been OP. So we know prima facie which beginner we're really talking about here. These are niche little applications only OP could love and if he's happy with them, I certainly can't force him to rewrite them. They are not manna from heaven. No one here is god's gift to programming.

I feel you and I are wasting our time trying to instill better shell scripting practices here. You can lead a horse to water, but you cannot make him drink.

aye... I think your correct.