Dear Sir,
why does split() command has different options in different UniX systems? i.e.
-a option does not work on some Unix machines... Is this because of long option
and short option difference?
Thanks,
YB
___
Bug-coreutils mailing list
Bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Yongsheng Bai on 12/9/2008 8:38 PM:
> Dear Sir,
>
> why does split() command has different options in different UniX systems?
> i.e. -a option does not work on some Unix machines...
Your example of 'split -a' is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[please keep replies on the list, and don't top-post]
According to Yongsheng Bai on 12/9/2008 8:51 PM:
> Thanks, Sir.
> But, how can I fix this problem?
> -
> split: invalid option -- d
> Try `split --help' for more information.
>
> split
source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
From: Eric Blake <[EMAIL PROTECTED]>
To: Yongsheng Bai <[EMAIL PROTECTED]>; bug-coreutils
Sent: Tuesday, December 9, 2008 10:00:1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Yongsheng Bai on 12/10/2008 12:54 AM:
>> split -C 30m -a 2 -d input.txt sub.
> split: invalid option -- a
> Try `split --help' for more information.
>
>
>> split --version
> split (textutils) 2.0.14
Wow. There's your reason. That is Y
file name and location are passed as parameters.
When I try to use the split command directly from console its able to
split the file. But when tried through the scheduler, its not able to
split the file.
The error message which is generated is "/usr/bin/split: arg list too
long"
On Wed, 9 Nov 2005, magesh sadagopan wrote:
When I try to use the split command directly from console its able to
split the file. But when tried through the scheduler, its not able to
split the file.
The error message which is generated is "/usr/bin/split: arg list too
long"
PROTECTED]
Sent: 09 November 2005 16:33
To: magesh sadagopan
Cc: bug-coreutils@gnu.org
Subject: Re: Split command problem
On Wed, 9 Nov 2005, magesh sadagopan wrote:
> When I try to use the split command directly from console its able to
> split the file. But when tried through the schedule
When I use the coreutils split command on a file. I get the parts with no
problem. But when trying the same exact command on the same exact file on a
different server the hashes checks of the parts vs the other server don’t
match. Is there a way to process a file the exact same way despite the OS
Hello,
On 2017-09-20 01:04 AM, Nick Farrow wrote:
> When I use the coreutils split command on a file. I get the parts with no
> problem. But when trying the same exact command on the same exact file on a
> different server the hashes checks of the parts vs the other server don’t
> mat
llo,
>
> On 2017-09-20 01:04 AM, Nick Farrow wrote:
> > When I use the coreutils split command on a file. I get the parts with no
> > problem. But when trying the same exact command on the same exact file
> on a
> > different server the hashes checks of the parts vs the ot
Hello,
On 2017-09-29 04:11 AM, Nick Farrow wrote:
> still with the same hash differences.
>
> split -b 3276800 -d largefile largefile.
I'm unable to reproduce this issue.
I've tried the above command on two different machines,
one of which is an RPi3 similar to yours (armv7l with split version
Assaf,
Thank you so much. when I was doing your steps I changed a few things on my
end to get the sha1sum of each part and I ended up removing the tar command
to speed it up. And from what it looks like the compression was the
problem. Each server was compressing differently compared to the other.
tags 28528 notabug
close 28528
stop
(triaging old bugs)
On 2017-10-01 6:09 p.m., Nick Farrow wrote:
[...] And from what it looks like the compression was
the problem. Each server was compressing differently compared to the other.
Given the above, I'm closing this bug.
-assaf
Hello,
I read at website:
http://www.gnu.org/software/coreutils/
the new features can be requested.
Recently I did some computations on machine
with whole system booted into ramdisk.
Due to lack of storage other than RAM, I only could do:
big-output-prog | split -b100m
and copy [to another
Hello,
I am using split command to split a large file and later I am renaming file.
PFB command.
find . -size +1000 -exec split -l 1 {\} {}-new \;
find . -type f -name "*new*" -exec mv "{}" "{}".list \;
However, this is giving correct result sometimes an
tags 17904 + moreinfo
stop
On 07/02/2014 11:16 PM, jayaprakash.vamb...@essent.nl wrote:
> Hello,
>
> I am using split command to split a large file and later I am renaming file.
> PFB command.
>
> find . -size +1000 -exec split -l 1 {\} {}-new \;
> find . -type f -
writes:
> I am using split command to split a large file and later I am renaming file.
> PFB command.
What does PFB mean?
> find . -size +1000 -exec split -l 1 {\} {}-new \;
This may find the newly created files, splitting them again if any of
the produced files is bigger then 1
-Original Message-
From: Andreas Schwab [mailto:sch...@linux-m68k.org]
Sent: 03 July 2014 18:41
To: Vambara, Jayaprakash
Cc: 17...@debbugs.gnu.org
Subject: Re: bug#17904: issue with split command
writes:
> I am using split command to split a large file and later I am renaming f
writes:
> Well, as far as splitting it to separate folder is concerned, I am sure the
> newly created files can never be more than 1000KB. Usually the split up files
> are around 250KB - 300KB in size.
The default unit for -size is actually 512 bytes, thus the limit is
500KB.
Andreas.
--
An
-
From: Bernhard Voelker [mailto:m...@bernhard-voelker.de]
Sent: 03 July 2014 08:13
To: Vambara, Jayaprakash; 17...@debbugs.gnu.org
Subject: Re: bug#17904: issue with split command
tags 17904 + moreinfo
stop
On 07/02/2014 11:16 PM, jayaprakash.vamb...@essent.nl wrote:
> Hello,
>
> I am us
tag 17904 notabug
close 17904
stop
On 07/09/2014 04:46 PM, jayaprakash.vamb...@essent.nl wrote:
I am able to resolve the issue now.
Thanks for the update.
I'm hereby closing the bug in our bug tracker.
Have a nice day,
Berny
Miroslaw Osys wrote:
> I read at website:
> http://www.gnu.org/software/coreutils/
> the new features can be requested.
Yes. This is the right place for the discussion. Pleased to read
your message!
> Due to lack of storage other than RAM, I only could do:
> ...
> I could execute:
>
> big-
> big-output-prog | ssh [EMAIL PROTECTED] "cat > somefile"
Thank you very much.
The cmd line you submitted is very useful.
Best regards,
Miroslaw
<>___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreut
I found the info page describing the
options for the split command somewhat confusing.
Hopefully the attached version is better.
Pádraig.
>From f6307e244b499f572fcdf0b8aa40450fa1ca5fdf Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]>
Date: Wed, 21 No
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> I found the info page describing the
> options for the split command somewhat confusing.
Thanks. Applied with a minor tweak.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu
Hi,
The split command does not accept anymore suffix with a length of 2 while it
was the default and still written as being so in the man page.
Version-Release number of selected component :
coreutils_8.8-2.mga1
How reproducible:
Always
Steps to Reproduce:
split -a 2 -b 10K /usr/bin/split
forcemerge 7759 10214
On 12/04/2011 08:03 AM, Xuo wrote:
> Hi,
>
> The split command does not accept anymore suffix with a length of 2 while it
> was the default and still written as being so in the man page.
>
> Version-Release number of selected component :
> coreutils_
28 matches
Mail list logo