bug#79488: [RFE] Enhancement idea : Better Handling of File Permission with CHMOD Command

>> Example (if possible): >> -- >> $ chmod 777 -t 30 myfile.txt >> # Grants full access to "myfile.txt" for 30 minutes >> # After 30 minutes, permissions revert to their previous state >$ chmod-t() { local m=$(stat -c %a "$2"); chmod "$1" "$2"; sleep ${3}m; chmod >$m "$2

bug#47243: pr lacks -p

Paul wrote: >ThenPádraig Brady wrote: >>Reading POSIX more closely I see there is also pause logic for the first page >>only: >> -f[XSI] [Option Start] Use a for new pages, instead of the ---^^^ (!) >>default >>behavior that uses

bug#47243: pr lacks -p

>Paul Eggert writes: >Thanks for looking into that. Unfortunately POSIX says -p should be >ignored only if standard output is a terminal, and that newline should -^ Shouldn't this be "ignored unless standard output is a terminal" ? >be read from /de

bug#79108: Meta Re: pr lacks -p

>On 2025-07-27 17:26, Stan Marsh wrote: >> Just out of curiosity, I note that you (Paul) say that "pr" is "obsolete". >> This surprises me, since I still use it every day. >I'm not proposing that we remove pr, just that it's not high priority.

bug#79108: Meta Re: pr lacks -p

Just out of curiosity, I note that you (Paul) say that "pr" is "obsolete". This surprises me, since I still use it every day. I find that, like a lot of the old style Unix utilities, it does what it says it does and that's good enough for me. In other words, you might then say the same thing (th

bug#79096: du: -x doesn't detect sshfs file system

>Maybe the -d option better suits your case then? > $ du -xchd 1 ~ Yes, that is nice. Thanks! (So many options; so little time to learn them all...) >Arguably, this doesn't skip "dot" files and directories, as the usual shell >globbing with '*' does. True, but I think I can live with that.

bug#79096: du: -x doesn't detect sshfs file system

>On 2025-07-25 11:25, Stan Marsh wrote: >> It could be argued that -x should cause it to skip (i.e., not descend >> into) any directory which is a mountpoint >That goes too far; people regularly use commands like 'du -x /mountpoint' to >list >just that

bug#79096: du: -x doesn't detect sshfs file system

> When the glob is expanded, $HOME/sshfs_mount ends up being one of the args > to `du' so it seems not surprising that the directory is processed. Yeah, you're probably right, now that I think about it. With "du", I prefer using ~/* instead of just ~ because then you get totals for each (top-lev

bug#79096: du: -x doesn't detect sshfs file system

> Thanks for reporting it. Can you use 'strace' to find out which system call is > hanging? That would help isolate whether the bug is in 'du' or is in the > kernel. It may have been imprecise of me to say it "hung" - in the sense of hanging on a single system call or operation. Rather, it stopp

bug#79096: du: -x doesn't detect sshfs file system

My du is: $ du --version du (GNU coreutils) 8.30 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted

Something strange with "date +%s" and timezones

I am in MST (US Mountain Time). My shell is csh. Observe: % date --ver date (GNU coreutils) 6.10 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. The

'file' command truncates at 31 characters (with long #! lines)

See below. At step 2, the 'file' command truncates the final 'F' in the filename. I'm assuming some buffer is only 32 bytes long, so only strings up to 31 characters are supported. Note that the script does work just fine (i.e., this version of Linux has no problem running a #! script where the