Serious question, why use a semicolon to put do and then on the end of the previous line?
Especially when do/done are the open and close control directives for a block.
Don't you think bash looks much cleaner when you use it how it was designed?
this post was submitted on 14 May 2025
56 points (100.0% liked)
Linux
56078 readers
428 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 6 years ago
MODERATORS
It's just a brace on same line/new line stylistic choice with extra steps.
About that, I used to also think that brace on new line is clearer, but after seeing a lot more code I have switched sides, both are clear enough to me, so I'd rather have fewer lines
Yes totally a personalstyle choice. To me, using a semicolon to save a line looks more ugly ; then ;)
Bash doesn't ever look clean.
In defense of OP, I do this a lot and go for similar moves in other languages too if the conditional bit is just a line or two. Pro choice!
I'd write
while true; do
X
done
for the same reason I'd write
if [ something ]; then
X
fi
or in another language
if (something) {
X
}
Because it's all part of the same statement and having a single line with just do or { seems silly and implies (to me) that the lines aren't related.
Agreed.
I also use this VSCode extension which formats my bash code using shfmt
I feel exactly the opposite.
while true do stuff done
looks much more clean to me.
It just looks weird to me to stick a semicolon into the middle of a line when a compound command isn't actually needed.
So you'd rather it all be on one line? I'd only do that if it's a very simple command, otherwise you're just making the code harder to read.
No the opposite. I think more shorter lines makes it easier to read than fewer longer lines.
while true; do
isn't exactly harder to read than
while true
do
though, is it?
And going back to my original point, I don't like while true being on its own as to me it looks like it's meant to be a separate statement rather than part of the do/done block.
Its a personal style choice.
With a blank line before the 'while' and another after the 'done' its a nice little easy to identify block. I don't know how the 'while' would look like its not a part of that block.
A midline semicolon just looks ugly to me so I don't do it unless it is the only way to make a statement work.
Not OP but this is how I learned it and how it's presented in the help file.
$ help while
while: while COMMANDS; do COMMANDS-2; done
$ help if
if: if COMMANDS; then COMMANDS; [ elif COMMANDS; then COMMANDS; ]... [ else COMMANDS; ] fi
Thats the concise help text to keep it short and easy to read.
The first line in the GNU Bash manual section on loop constructs says "Note that wherever a ‘;’ appears in the description of a command’s syntax, it may be replaced with one or more newlines."
Out of curiosity, and because I work in XR, what do you used those glasses for?
What company do you work for in XR?
I got the XReal One as a portable ergonomic monitor and I may use them as my main monitor going forward. I have a sit/stand desk with monitor arms which I can adjust the height and position for an ergonomic design to always look straight at the monitor and not looking down.
From my research currently the XReal Ones are the best AR/XR glasses on the market due to the chip built into them, not needing any other devices or software to run, just plug in play. The XReal One Pros which I think are coming out soon have some better specs but to me, not worth the extra money.
I been using them for regular desktop/laptop task and coding and I prefer to use the anchor mode when doing this. I sometimes also use the ultra-wide mode to simulate 2 monitors. I also been using them for gaming and I will either have it in follow or anchor mode but never use ultra-wide mode for gaming.
Mine, we're one in it, me ;)
Interesting, thanks for sharing the use cases and clarifying your choices.
I do also have a standing desk with a relatively large screen on a monitor arm. I also have a walking pad under the standing desk. The goal being to ergonomically have as much freedom as possible while still being efficient.
I did try the XReal months ago but I don't think I tried the Pro.
Otherwise I worked with pretty much everything (Google Glass, HoloLens, Vision Pro, Quest (all models), Lynx XR1, Monocle/Frames, my own DIY ones, etc) but my main focus is WebXR and 6DoF, so not really replacing a screen. I do understand it is useful, and sometimes as I travel I use the Quest 3 or Vision Pro to work in there but that's typically a temporary measure. My professional perspective is that 6DoF with hand tracking and accessories (6DoF pens, BT keyboard, etc) is the most novel way to interact with information hence why I build open-source WebXR prototypes on that topic.
What about the condition that when the external display is disconnected, the main display should be reenabled?
You should not need an else if statement to re-enable the internal display. When no displays are enabled, it will enable the internal display. This was the case when I tested it.
Agree.
However, I always have those "trivial" conditions be explicitly set. Usually, when the device is unplugged correctly, your primary display will be automatically be turned on. However, in very weird scenarios (incorrect voltage signals, loose wire, etc), it's possible that the explicit else condition will be triggered.
How about watch -n 5 your_command instead?
Anyway an event based solution, maybe via xev filter on randr category could be more elegant. Still, whatever works for you! Thanks for sharing.